The build jobs building all osmocom components which will be used by the
osmo-gsm-tester. A .tgz archive will be used as artefact which is copied
later by the osmo-gsm-tester test run.
Change-Id: Ic49c94e9e6639e43f6ae14b868bc826af3ce2085
libuhd-dev would recommend uhd-host which seems not be installable on debian jessie in an lxc.
However we should have already listed all explicit dependencies and shouldn't need
anything else
Change-Id: I6859b8180916a8e172d32030da06ba6fa27d5c45
Avoid as many multiple triggers as still ensure all dependent projects are
rebuilt correctly. Keep the full trigger list as comment, and illustrate in a
comment at libosmocore how the chain is intended to work.
Change-Id: Iea2cf25b3872045778f11a985a1c417f37067cd9
In case we provide a tag, origin/$tag doesn't resolve correctly, we must
use $tag. Same happens probably if we want to build against a specific
commit hash.
Change-Id: Ica50080c8b3e20686fe6f47a2b61718ef4a66d95
proot crashes with current jenkins node setup, which means we cannot use
it to run ARM based axis.
proot bug is already reported upstream in:
https://github.com/proot-me/PRoot/issues/134
Related: OS#3061
Change-Id: I9bc48349c78f395b3842bc5caaf6e948fb4c299e
Introduce playbooks to do:
- setup-jenkins-slave - setup a usualy or special jenkins-slave
- setup-gsm-tester - setup the gsm-tester
Change-Id: I7007a4e6c38f73843390ec2b3b91133aff21e36a
Introduce more precise labels to allow more flexibility when extending the jenkins setup.
The linux_amd64_debian8 or linux_amd64_debian9 is used across all build jobs which
make it hard to add new nodes which might only support one group of
jobs.
Change-Id: I900b7b50b33cc95e127ca78d2a47f59d32a6dfee
Introduce more precise labels to allow more flexibility when extending the jenkins setup.
The linux_amd64_debian8 or linux_amd64_debian9 is used across all build jobs which
make it hard to add new nodes which might only support one group of
jobs.
Change-Id: I0fa3d3f81ab01e2488fe07601740f42eb54b6d9c
In osmo-ttcn3-hacks Idc165425b45872d2eb958a662d03e69aaf60669d
we introduced the new 'deps-update' Makefile target to properly
update all 'deps' repositories without removing them. Let's use it.
Change-Id: Iabc54182d1d30ef26e4f72fb9db52fd25a6c9800
There were a lot of downstream triggers that we were missing.
I manually reviewed the debian/control files and used that to update
the trigger lists for all jobs in master-builds.yml.
Change-Id: I12057c9bb389041ef3bcabd1c335a0fa8c358092
The sequential parameter was silently skipped because it was absent from
the project template. Fix this for both master- and gerrit- jobs.
Change-Id: I0bc28695f4f270bc7b1cc4bcd5d4d43ede6172f3
The jenkins.sh is just a tiny wrapper around coverity_Osmocom.sh - let's
remove this unnecessary indirection and move the code directly to
jenkins.sh
Change-Id: Iead3b8f39327f1d0dd80e12a9d38563c35701993
Get rid of job name comparison because it depends and exact build server
name and hence is highly fragile. Use dispatcher script the same way we
do in osmo-bts.
N. B: this requires I2955e866bce4f000a53369bd601a346c36c82468 in
libosmocore.
Change-Id: I76dfc11a05007ae5c6e0554fe8132695b67cccaa
Recently we had changes to osmo-ci, and I noticed that although some master
builds were broken by that, the builds were still showing success -- of twenty
days ago.
Run each master build at least once a day to indicate odd side effect failure
sooner.
Change-Id: I126de2bab3db22cb693b0fa665f6579de9238fdf
The vty and ctrl tests are enabled by default and are run on hard-coded
ports. This causes some builds to fail when run in parallel.
Change-Id: I23d5b75825a667e4f043d16a12b841cd8f01af5e
The pip(2|3) tool is the officially recommended tool to deal with Python
packages [1] with much greater flexibility compared to invoking setup.py
directly. As a preparation step for using it to install
osmo-python-tests let's add it to container images.
[1] https://packaging.python.org/guides/tool-recommendations/
Change-Id: If2702c71cd268ca688e9ecc264f8cd1257c27899
Debian 8 contains quite old qemu and proot packages which have some
issues running the chroot infrastructure set up in osmo-trx's
jenkins.sh.
Change-Id: I24665880fff5a5b918bb6ffaf1e7bb51ae860b0b
Building a docker image depending on a debian upstream has the problem that an
intermediate build result will depend on an APT package archive that is
probable to become outdated. It's necessary to do an 'apt-get update' regularly
to get the newest package archives and be able to install new packages. We
never know which 'apt-get install' steps we might be editing, so we'd have to
add an 'apt-get update' before each, or use an ADD line to find out whether the
package archive has changed, before each and every apt-get install step. We're
likely to miss those in the future, and it would be a large, complex change.
Instead, try to build the docker image with --no-cache in case a cached build
has failed. This should fetch the most recent debian upstream with a proper
archive.
Fixes the current problem that the rebuild_osmocom_jenkins_image.sh is stuck on
various build slaves, should trigger a --no-cache build on each slave.
Change-Id: I37110287dabd53d3537d94ecd74cf513396971b3
Recent change I8f5012419495a656912b7b71e4f76ce102c6b63a adds use of stow in
osmo-build-dep.sh, hence our jenkins build processes now require the 'stow'
dependency. Add 'stow' to our debian docker images, used for various builds
(those that invoke 'docker' in the jobs/master-builds.yml and
jobs/gerrit-verifications.yml to produce concurrent builds).
A recent commit made this change in the Dockerfile.deb8_* dockerfiles, in the
assumption that the jenkins one would depend on that, which is actually not the
case. Instead, add stow in the dockerfile that is actually used in the jenkins
jobs. (It is not harmful to still keep the added dependency in the other two
dockerfiles.)
Change-Id: If97176f4aea66c42a6820f14ceb4b91369841ca0
Recent change I8f5012419495a656912b7b71e4f76ce102c6b63a adds use of stow in
osmo-build-dep.sh, hence our jenkins build processes now require the 'stow'
dependency. Add 'stow' to our debian docker images, used for various builds
(those that invoke 'docker' in the jobs/master-builds.yml and
jobs/gerrit-verifications.yml to produce concurrent builds).
Note: the Dockerfile.deb8_i386 doesn't seem to be used, currently. Add stow
there anyway.
Change-Id: I7a44ba5ed130a3311460185507f76151c6daa7f1
Alexander Couzens
Pau Espin
Harald Welte