Feature #5981
closedobs.osmocom.org project/package feed for TIC/Rhizomatica
100%
Description
TIC/Rhizomatica is using the osmocom:latest feeds for most of their osmo-* packages on their (mostly Debian 10) machines, but have a few self-built packages on top (from a private feed).
We've discussed two topics during a recent call with keith:
- having a feed for testing patches/fixes in situations where one of the osmocom developers has some not-in-latest patch that they want to deploy to (and test) on certain TIC/rhizomatica networks
- this feed should automatically build packages from osmo-* git repo branch, e.g.
rhizomatica/testing(if such a branch exists) - this feed would only contain those packages for which currently said branch exists. All other packages are used from
osmocom:latest - if said branch is removed form a given osmo-* git repo, the package should also disappear, making the version
osmocom:latestagain the best available version
- this feed should automatically build packages from osmo-* git repo branch, e.g.
In addition, there was also the suggestion whether or not the custom, hand-built production packages on TIC/Rhizomatica systems could be built via osmocom.org jenkins/obs. This would remove the burden of manually building those packages and maintaining related feeds, and instead keith would just push to a related branch on the git repo at osmocom.org, which would trigger the package build, ...
It could use the same mechanism as suggested for rhizomatica/testing above, resulting in the following hierarchy:
osmocom:latestas basis/fall-back.- feed configured on all TIC systems
rhizomatica:productionfor those packages that require additional rhizomatica-specific patches.- uses
osmocom:latestto resolve its depenencies - only built for packages where a related
rhizomatica/productionbranch exists in the osmo-*.git repo. - feed configured on all TIC systems
- uses
rhizomatica:testingfor very few select packages where any of us wants to test something on a TIC system- uses
rhizomatica:productionto resolve its dependencies - only built for packages where a related
rhizomatica/testingbranch exists in the osmo-*.git repo. - feed configured only on some (typically one) TIC system to test a specific code change
- uses
The most relevant distro for those builds right now is Debian 10. Not sure if only x86_64 or also 32bit x86 builds are required?
Checklist
- set up OBS projects rhizomatica:testing, rhizomatica:production
- write jenkins jobs that trigger on changes to related branches, and update or delete the packages from the rhizomatica OBS repositories
- deploy packages from OBS
Updated by osmith 2 months ago
- Description updated (diff)
- Status changed from New to Feedback
- Assignee changed from osmith to keith
Sounds good.
- Can you push the
rhizomatica/productionbranches for the projects where you currently use custom patches? - Which projects are these?
- Which projects are relevant for the package feed in general, where do we expect to have such rhizomatica branches in the future? (we could also do all, but as it's probably just a few of them we can save some iterations of checking git commits from remote repositories etc.)
Updated by neels 2 months ago
I just added SYS#6415 to ask whether i can get a custom package build by
pushing a git branch. Just would like to relate that here, in the sense of:
when osmith is already setting up a custom build for rhizomatica, then maybe it
is quick to also setup another 'sandbox' feed at the same time?
Updated by laforge 2 months ago
osmith wrote in #note-2:
- Can you push the
rhizomatica/productionbranches for the projects where you currently use custom patches?
AFAIR they are https://gitlab.tic-ac.org/ but are unfortunately not publicly browsable.
- Which projects are these?
Anyone participating in the call last week and/or able to access rhizomatica systems can just log into a system and check. From my memory it was mostly osmo-msc at this point, possibly osmo-hlr, too.
- Which projects are relevant for the package feed in general, where do we expect to have such rhizomatica branches in the future? (we could also do "all")
I'd go for a generic solution. You never know in advance. Any Osmocom CNI repository should be covered.
Updated by osmith 2 months ago
- Checklist item set up OBS projects rhizomatica:testing, rhizomatica:production added
- Checklist item write jenkins jobs that trigger on changes to related branches, and update or delete the packages from the rhizomatica OBS repositories added
- Checklist item deploy packages from OBS added
- % Done changed from 0 to 80
Patches: https://gerrit.osmocom.org/q/topic:rhizomatica-repos
It's working as described above, as soon as one pushes to rhizomatica/testing or rhizomatica/production branches of any Osmocom repository (that is in gerrit), a source package gets built and updated in OBS. When deleting the branch, the job also gets triggered and deletes the package from OBS.
As discussed with Harald, the part of publishing the built packages from OBS is not implemented yet.
Updated by osmith 30 days ago
- Status changed from In Progress to Feedback
- Assignee changed from osmith to keith
The remaining part is publishing the packages built by OBS.
Harald told me it would be better to not make them part of https://downloads.osmocom.org/ as otherwise people may assume that they are meant to be used by anyone. (Which is of course not the case as they will have WIP/debug patches for rhizomatica's use case, regular users should use the repos as described here)
keith: can we upload the packages directly to a rhizomatica server via rsync?
