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
This commit introduces the usage of GNU stow[1] for dependency
management.
Stow uses symlinks to make dependencies available in a single directory
althoguh they were installed in distinct directories.
Keeping installation directories seperate has the advantage of letting the
build fail if AM_CFLAGS and LDADD do not contain all dependencies which are
actually used.
Installing multiple dependencies into a single directory causes x_CFLAGS
and x_LIBS variables to magically point where other dependencies are
found as well, therefore missing entries can be overlooked.
Stow acts as a convenience layer here, making it unnecessary to supply a
list of locations in LD_LIBRARY_PATH, PKG_CONFIG_PATH and so forth for
building when dependencies are installed in distinct directories
manually.
Stow has to be present on the jenkins build nodes for successful executing of
osmo-build-dep.sh.
[1] https://www.gnu.org/software/stow/
Change-Id: I8f5012419495a656912b7b71e4f76ce102c6b63a
The [yes, no] tuple was automatically converted to [True, False] by the
jenkins-job-builder but the combination filter still used old literal
check. Fix this by using boolean from the very beginning.
Change-Id: Idac6e53b1e0addbcb5b6c99b8051e1e0ad26bc5b
No need to duplicate the install steps we have in osmo-python-tests/contrib
now. Also runs the tests.
Change-Id: Ibb8eb04e3a5c9c5dcc9b99c83425d2604378f960
Make sure that python-setuptools are installed for both python v2 and v3
to make sure osmo-python-tests can be installed.
Change-Id: I3ecd96af2e2c0c7d141977639103d71e46c0cdc5
Related: OS#2821
It was disabled back in a days when it was dependent on a separate
branch. Thisis no longer the case so we can enable it back. Also remove
remaining leftovers.
Change-Id: I5fd3bdab217b61f9ee50a5f1413b60d396535395
Notify intern@ if either update-osmo-ci or update-osmo-python jobs
failed. Those are essential for our CI and test infrastructure so we
should look into related failures right away.
Change-Id: I0d51e35424a26eab7d38152e13f3ac6fd3f3997c
Related: OS#2821
Harald Welte
Neels Hofmeyr
Pau Espin
Alexander Huemer