validate debian rules/control as part of jenkins build testing
Right now one can make changes to the source code that will break the debian package builds.
It would be nice if the jenkins build testing for +Verified in gerrit would trigger a dpkg-buildpackage of the related code. This is probably a good case for a docker container that has all known/shared required packages installed?
- % Done changed from 0 to 10
I've done some testing and research to figure out the best way to implement this.Caveats:
- we must also build debian packages of all dependencies, and install them beforehand
- ideally we would build the debian packages in a fresh debian docker container, and use "apt-get build-dep ."
- building all dependencies and the project that was modified itself will take just as long as the current build job
So this is more than just a simple change in each project's jenkins.sh script.
Since this takes at least as long as running the current jenkins.sh, I think we should run it in parallel to jenkins.sh.
It would also be nice if we did not have to modify each repository to implement this, so I'd put a common script in osmo-ci.git instead.Concept:
- create a new script in osmo-ci.git, which:
- builds debian packages for all dependencies of a program, each in an empty docker container and by installing dependencies with "apt-get build-dep"
- already built dependencies get installed in that empty docker container first
- finally build the debian package for the project that we are currently verifying
- adjust gerrit-verifications.yml and master-builds.yml to run this script in parallel to the existing jenkins.sh for the projects where we want to test this (using build axes?)
This is not as trivial as I thought, so I will not continue with this issue right now.
What about using the nightly debian package feed for all the dependencies? Yes, that
poses some kind of danger during a day, (i.e. libosmocore patch is merged, and one hour later
somebody wants to verify a patch using that feature in osmo-msc), but maybe that's acceptable?
In order to improve on that, we could also be something like a "master" package feed which rebuilds
packages as soon as a commit is made to master. This could probably be done using OBS, as rebuilding a
single package after a commit to our master (e.g. libosmocore.git) should be relatively quick compared to the
full-rebuild-everything on nightly? If OBS is not suitable, we could also have a different mechanism (like
pbuilder), but I would argue for trying OBS first. At least it should get the propagation delay from
"libosmocore patch was merged" from one day (nightly feed) to some (tens of) minutes.
This way we avoid rebuilding all dependencies all the time, which looks like a rather big waste
of time (and energy) to me.