jenkins job generating tarballs of all tagged releases
It would be great to have a script (which could subsequently be executed by a jenkins job) that would generate tarball releases for all our tags.
So basically something like:
foreach repository: foreach tag: autoreconf -fi && ./configure && make dist
If some older tags don't build [anymore] we could either explicitly blacklist them, or we simply build only tags no older than N years.
The resulting tarball releases should be collected somewhere in a directory which could then be subsequently rsync'ed to a public server/directory.
- merge osmo-ci.git patches
- merge docker-playground.git patches
- enable this job's e-mail notifications (currently disabled, because patches are not merged)
- rsync the result to another server
#6 Updated by osmith over 1 year ago
- Checklist item merge osmo-ci.git patches added
- Checklist item merge docker-playground.git patches added
- Checklist item enable this job's e-mail notifications (currently disabled, because patches are not merged) added
- Checklist item rsync the result to another server added
- % Done changed from 50 to 70
- This iterates over all Osmocom repos and tags, and builds release tarballs.
- I've added a blacklist for versions where the release tarball can't be generated.
- For osmo-mgw I've added a workaround, because the release tarball can't be built for the last 5 versions or so, including the latest one (#4084)
- The script creates a _release_tarballs dir in the jenkins workspace, and puts all generated tarballs there. It skips the ones that are already generated.
- Tags are queried from the git server without cloning the repos. The git repos only get cloned when we need to generate a new tarball. When the script is done, the git repos are deleted again to save space (all checked out git repos are about 500 MB in size).
I have also added the jenkins job. The script needs to run in docker, otherwise ./configure will complain that various libraries are missing. I've added "debian-stretch-build-dist" to docker-playground.git, which installs the various -dev packages on top of "debian-stretch-build". The jenkins job builds that docker image with a new function in osmo-ci.git's script/common.sh, and then runs osmocom-release-tarballs.sh inside the container.
The output of the script looks like this:
... osmo-hlr osmo-hlr-0.0.1.tar.bz2 (ignored) osmo-hlr-0.1.0.tar.bz2 (exists) osmo-hlr-0.2.0.tar.bz2 (exists) osmo-hlr-0.2.1.tar.bz2 (exists) osmo-hlr-1.0.0.tar.bz2 (creating) ...
#8 Updated by osmith over 1 year ago
#10 Updated by laforge over 1 year ago
On Wed, Jul 03, 2019 at 11:54:33AM +0000, firstname.lastname@example.org wrote:
Could you set up a new account for the releases, like the existing docs
I do not have the required credentials with me on the old, non-work laptop that I
carry with me on the motorbike tour during holidays. I can look into
this once I'm back, please ping me then (July 16).
Sorry for dragging this too long.
I tried to make it work, but the fact that it's built inside docuer doesn't make things easier.
In https://jenkins.osmocom.org/jenkins/job/Osmocom_API/configure we use the jenkins credential store with SSH agent forwarding to make the upload work
I would prefer a similar solution. There's now a http://ftp.osmocom.org/releases/ directory that you can rsync to (port 48)
I will add a related 'releases' ssh key to the jenkins credential store.