Here, the job names are not the same as the directory names of
docker-playground.git
Related: OS#3208
Change-Id: Idbcb7267ce38cbdc2df5631df404f908487f827b
Change the description of the job, to make it easier to use for somebody
not familiar with the Osmocom stack / the testsuites. Move the BRANCH
parameter to the bottom, as it is not relevant for kernel developers who
want to test their kernel, and adjust the description.
Related: OS#3208
Change-Id: I0968ae716c8e3f32db6f589b28d6066d95ad85ea
Let the user choose whether to run against osmo-ggsn latest or master.
I chose the name "OSMOCOM_VERSION" for the variable to make this easier
to use for people not familiar with the Osmocom stack / the test
infrastructure, as suggested in the related issue.
Related: OS#3208
Change-Id: Ifaf8ed6502b469ade670c3f436670480d27becd6
Add new nightly jobs, as requested in OS#3208:
- ttcn3-ggsn-test-kernel-latest-torvalds
- ttcn3-ggsn-test-kernel-latest-net-next
Note that they are in ttcn3-testsuites.yml and not
testsuites-kernel-git.yml, because the KERNEL_URL etc. parameters are
not configurable. These new jobs are supposed to run every night with
the same hardcoded git repositories, the other job from
testsuites-kernel-git.yml is for manual runs with a freely configurable
kernel URL.
Depends: docker-playground Iaef87c3418b8e6f1e427b2abd9d40e9e28dc63e9
Related: OS#3208
Change-Id: I6918b953b64b0d81805fd02b1a8469a8db20f938
Move ttcn3-ggsn-test-kernel-git into its own file, so the parameters
that are only relevant for cloning a kernel from git, do not show up in
all other TTCN-3 jenkins jobs.
Related: OS#3208
Change-Id: Iafbe6139db47c2918dc1fd7c3bacf38da326d9c8
Fix osmo_obs_add_rpm_spec() to not assume to be in the $oscdir.
This caused the following error when being called from
osmocom-latest-packages.sh in the code path for adding a new package:
ls: cannot access 'osmo-gbproxy_*.tar.*': No such file or directory
Related: OS#5051
Change-Id: I467e332b69accfabba53332fdb9cd785991855fc
As decided in the meeting, disable jobs in the config instead of
manually disabling them in the web UI.
Change-Id: I11e9504cace39d7377e993537c6746fe154b3f12
Make it possible to run the jenkins job with a different kernel
repository, by exposing KERNEL_URL, KERNEL_REMOTE_NAME and
KERNEL_BRANCH.
Related: OS#3208
Change-Id: I5d4202a67a24d9c15a5b211fa29ce9d5b5a9d9c1
Change the name of the job to ttcn3-ggsn-test-kernel-git. A follow-up
patch will add parameters to the jenkins job to specify a different
repository than net-next, therefore the generic name makes more sense.
Related: OS#3208
Change-Id: I409f49f88f0a75c782dd3c90c5051e8287644138
Replace the current logic, that would only run osmo_obs_add_rpm_spec
when adding a new package, or when the version of a package has changed,
with running it every time.
Running the command when it is not needed does not hurt, as it does not
take significant time, and osc does not attempt to upload the file when
it did not change.
The advantage is, that we can update/upload the spec file without
tagging a new version, if a bug prevented it from getting uploaded
before (as it just was the case for all Osmocom packages).
Related: OS#5054
Change-Id: Ie067c97b5f54ec5b3309ddbd2bfb7f846cd0ccd3
Pass the path to the project's git repository to osmo_obs_add_rpm_spec,
instead of $output (has the output of "gbp buildpackage").
Related: OS#5054
Change-Id: I799398120ab0cbdb74b2d74a3fb139395d66d449
Make a separate commit for the distro specific patch, instead of using
"git commit --amend". Otherwise, if HEAD was pointing to the latest tag
before the amend, git-version-gen will use the previous tag instead of
the latest one after the amend.
Fixes: OS#5053
Change-Id: I67770a19ee60101df989f98673a22705ad50beed
In previous patch 27ee885a68, I made sure
that "apt-get update" runs before trying to install wget to download the
repository key. But of course the OBS repository should not be present
before installing the repo key, or else it will fail:
E: The repository 'http://download.opensuse.org/.../Debian_10 ./ InRelease' is not signed.
Fixes: 27ee885 ("repo-install-test: apt update before install wget")
Change-Id: If79484f9ffe2a14ce6481b53867f5aee111aa11b
Run osmo-ggsn ttcn3 tests against the gtp kernel module from the debian
kernel and from HEAD of the linux netdev/net-next git repository.
Depends: docker-playground I1f337af1e2de6db05b22636bc31a535404235559
Related: OS#3208
Change-Id: I4c496af78820d95549da22c1271bafe911f7eefb
Move 'cd' and './jenkins.sh' commands towards the end, so they are not
repeated in the case block of each pattern. This is in preparation for
the ggsn kernel mod test, which will need new patterns.
Related: OS#3208
Change-Id: I0fac24b961b1abb09317144ec2f65d4e21eb70c2
Prepare for the ggsn kernel module test, where we don't want to wipe the
workspace with the cloned linux git tree.
Related: OS#3208
Change-Id: Ic5843513c376d2b78be8ab90b21a747d31a827f1
If epoch is used in debian/changelog, prepend it to the version from
git-version-gen. Also set the epoch in the spec file.
For example, the version in debian/changelog may be 1:0.0.1. The epoch
is 1, therefore a 0.0.1.18.b5d18 version from git-version-gen would turn
into 1:0.0.1.18.b5d18.
Setting epoch=1 is needed for osmo-gbproxy, so apt on debian 10 with the
nightly Osmocom repository enabled does not try to install osmo-gbproxy
1.3.0 from the debian repositories instead of 0.0.1 from the Omsocom
repository.
Related: https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
Related: OS#4992
Change-Id: I3d63f040058340bdcf9075c03387798c5314be03
Trigger registry-rebuild-upload-titan on changes in
osmo-ttcn3-hacks.git. Write registry-triggers.yml with a job template,
so we could add more triggers from git repos -> registry easily if
needed in the future.
Related: OS#5017
Change-Id: Ib6a27be6351ce821c7023a1f75a82b1ade2ffa49
Add the slave axis again, so the jobs aren't stuck forever. I had
assumed that without the axis, it would run on any node, but that's not
how it works. Add a label for this job, with several nodes attached,
like we do it for TTCN-3, master-builds, gerrit-verifications etc.
Related: https://jenkins.osmocom.org/jenkins/label/repo-install-test/
Related: OS#4567
Fixes: fcf669 ("repo-install-test: run on all build slaves again")
Change-Id: I276ab47f76a0f4db542ca99825ebb019236b4d27
It was not possible to reproduce the weird rpm errors on
admin2-deb9build, which had lead to limiting the build slaves to
build2-deb9build-ansible. Enable building on all again.
Closes: OS#4567
Change-Id: I82ef1f0c581de8ee826adedd9ecde6b4adaa36ba
osmo-cbc has full support for building dpkg + rpm from the latest
tag (0.2), hence we can enable building it also in 'latest'
Change-Id: Ia5bfd126ad168da7ab629b1f18ecfd60d4a49a51
Stop downloading bumpversion related archives with each run. They were
not uploaded to OBS after the download (no 'osc add' runs aftewards, and
last modified of network:osmocom:nightly:bumpversion is 3 years ago).
bumpversion is needed to run osmo-release.sh, and is available in debian
since 9 (stretch).
Related: https://build.opensuse.org/package/show/network:osmocom:nightly/bumpversion
Change-Id: Iaf2527043e9acdb6acff3e481d4516ac4b75b7e7
If the repository doesn't have a git tag yet, git-version-gen will set
the version to UNKNOWN. The debian package build tools will choke on
that, so fall back to using the version from debian/changelog.
Related: OS#4992 (osmo-gbproxy.git doesn't have a tag just yet)
Change-Id: I43c32f73bdfd715db5afdeec3bd8026d3c1fd8eb
A valid example is "centos8", with the version, not "centos". Remove the
debian example, as we'll require a version with that later on as well.
Related: OS#4969
Change-Id: Ie8c2c86bc77606b1d2d4339751521139de22db04
Instead of hardcoding CentOS_8 in the centos code path, and Debian_9.0
in the debian code path, resolve the proper OBS directory based on
$DISTRO.
Related: OS#4969
Change-Id: Ie537e8befeebd7958b2a1fe8f6fd54587cfcb1b6
Instead of calling various foo_debian and foo_centos8 versions with
foo_$DISTRO, create new foo functions that call the right
distro-specific function based on debian* or centos* being in DISTRO.
Rename all foo_centos8 functions to foo_centos.
This is in preparation to run this script with debian10 too, not just
debian9. This can also be used to test a different centos version in the
future.
Related: OS#4969
Change-Id: Ibb9f93af16af7ebe947f7efcd4e709f3e62d12c0
Give OBS more time to build the repository, before verifying that we can
install all packages from the repository. Apparently, OBS publishes the
repository in WIP state, before all packages for a distribution have
been built.
This leads to problems in the "nightly" and "next" repositories. In
contrary to "latest", we do not bump soname versions when doing ABI
changes, so we require the user to have all installed Osmocom packages
built from the same timestamp. With recent changes in the OBS scripts,
we enforce this by having all packages built from the same timestamp
depend on the exact version of a dummy package with that timestamp as
version.
The repo-install-test installs all packages from the binary repository,
and so it fails, as it should, if the repository is in an inconsistent
state with some packages built today and some packages built yesterday.
Related: OS#4733
Change-Id: I8df9b449d6213b5dca6fd9bf5c06b5c96d468f66
Install one Osmocom package from one package feed and attempt to install
a second package from a different feed. Verify that the package manager
exits with error and mentions the conflict in its output.
Related: OS#4733
Change-Id: Icf2a3a1d1de2ff42b1dc9aadf2075e5e1ff40291
Oliver Smith
Harald Welte