For a long time I was using '{}' to indicate a nulled out struct. But
apparently '{0}' is the favored way to write that. Let's allow using
this notation to terminate a value_string[].
Change-Id: Id2f5ba897ec83f34f8d3c4425353c0baf309bb6d
Let's use newer debian to avoid problems with older erlang. Furthermore,
the new image builds rebar3 to avoid issues with unmatching erlang
versions.
Change-Id: I7b1956c515daccf6ab1ff87031c6fec649cadb4b
Only run the simple image clean code if docuum is not running. It works
well enough in most cases, but has the drawbacks that it never deletes
"latest" images or images not matching "^osmocom-build", and may delete
images that are still being used (OS#5447). With the other tool, all
images are considered for removal, and the ones that have not been used
the longest time are removed first.
Related: OS#5477, OS#5066, SYS#5827
Change-Id: I1cef0833c096de0fa5acf77156bb5dd362e2ef9c
Do not only clean up dangling images, but also containers, volumes and
networks.
Related: SYS#5827
Change-Id: If441b251de50063f0229d36fb1bc260a4cb1dd87
Clone simtrace2.git before trying to create the tarball with git.
Fix for:
simtrace2
simtrace2-0.1.tar.bz2 (creating)
+ cd /osmo-ci/_temp/repos/simtrace2
/osmo-ci/scripts/osmocom-release-tarballs.sh: 195: cd: can't cd to /osmo-ci/_temp/repos/simtrace2
Related: OS#5347
Fixes: 0221a0 ("OSMO_RELEASE_REPOS: add simtrace2, osmo-remsim")
Change-Id: I0a845549ba1fe9f0d9ab55a5c5c7bf5b8f57caae
Adjust to simtrace2's directory structure, which does not have a
configure.ac in the main directory like all other repositories. The main
directory has a regular Makefile without autotools, only the host dir
has a configure.ac file (and only in newer versions). Deal with this by
creating two tarballs, one with "git archive" for the whole directory,
and one for the host dir only with the usual "autoreconf -fi;
./configure; make dist-bzip2". The latter one has the files created by
autoreconf ("configure" script and others).
simtrace2
├── simtrace2-0.1.tar.bz2
├── simtrace2-0.2.tar.bz2
├── simtrace2-0.3.tar.bz2
├── simtrace2-0.4.tar.bz2
├── simtrace2-0.5.1.tar.bz2
├── simtrace2-0.5.tar.bz2
├── simtrace2-0.6.1.tar.bz2
├── simtrace2-0.6.tar.bz2
├── simtrace2-0.7.0.tar.bz2
├── simtrace2-0.7.1.tar.bz2
├── simtrace2-0.8.0.tar.bz2
├── simtrace2-0.8.1.tar.bz2
├── simtrace2-host-0.6.1.tar.bz2
├── simtrace2-host-0.6.tar.bz2
├── simtrace2-host-0.7.0.tar.bz2
├── simtrace2-host-0.7.1.tar.bz2
├── simtrace2-host-0.8.0.tar.bz2
└── simtrace2-host-0.8.1.tar.bz2
Closes: OS#5347
Change-Id: Ib52a23a2a7d6ea64bfa539b1d026f035fdb3af57
Old osmo-msc releases failed to build because logging output of
libosmo-mgcp-client has changed. I'm backporting the fix as 1.7.1 and
1.6.4. The script builds the last 3 releases (1.6.4, 1.7.0, 1.7.1), so
mark 1.7.0 as known error.
Related: osmo-msc Id197e4ab9ba12e284299ef520edee9c362513bf1
Change-Id: I86f8252d450165f4be3d7c97fa70235638f7dd96
Drop these workarounds, as we are not building binary packages for
debian 8 anymore.
Related: OS#5223
Change-Id: Ibe7ba124557969df62798ba49c4489e9606c2341
Disable osmo-pcap-server for latest again, as the port is still
conflicting there with osmo-bts.
Fixes: 7ca9c4 ("repo-install-test: clear SERVICES_NIGHTLY list")
Related: OS#5203
Change-Id: I711e0e13c3e3af30407b85fd10aca9446f2b94ba
All services that start up in nightly should also start in the latest
release now, as new versions have been released of related programs.
Change-Id: Idc94270978ec5ca67d6f7e20e009f905e972f984
Use the nightly script instead of latest, so all packages get
upgraded when upgrading osmocom-2021q1.
Related: SYS#5370
Change-Id: If8de585652997aae1edb586c948c181f564f6994
Determine the package name of the conflict package itself and all
conflicting packages automatically, so we don't need to have it
duplicated in the OBS latest and OBS nightly scripts.
This is in preparation to move osmocom-2021q1 from latest to nightly.
With the current logic in nightly for the conflict package, it would not
be possible.
Related: SYS#5370
Change-Id: I183b9040250e66e0d7d17ef4b95af9e7d4a26f04
Allow overriding OSMO_OBS_CONFLICT_PKGVER, so we can increase the
version of the osmocom-2021q1 package whenever something changes on one
of the 2021q1 branches.
Related: SYS#5370
Change-Id: Iae45d7462aab8227ed3756e6cccfa3e64cb04211
Add a simple helper script to run osmocom-*-packages.sh in docker to
avoid installing dependencies on the host system.
Related: SYS#5370
Depends: docker-playground Ibb55ad18d2ccf4313f52fa3e3c10d4420c84dced
Change-Id: Icc89e20950c2aaa67b209340d1d797b76fce32d2
Move get_commit_version to common-obs.sh and call it in
osmocom-latest-packages.sh, if the feed is not "latest". This way, the
packages don't have the latest tag as version anymore, and the version
changes if commits get pushed to the feed's branch.
Related: SYS#5370
Change-Id: I4a4fa3b8f66652ef36a7fe62047a88a69c473f19
Move git_version_gen calls into an own function and add some of the
description from I76e3713f0b01a6110091ff90e8e53aa79533c374 where this
code was added.
Don't call it inside get_commit_version anymore, but call it before.
Don't try to cat the resulting .tarball-version there if it doesn't
exist.
Related: SYS#5370
Change-Id: I9a1b6ae4b4311abb77dc6390733c5e330e3d489e
Skip checking out and building source packages of all other packages, if
the environment variable is set.
Related: SYS#5370
Change-Id: I83c3744713fd6abda4b832460f30eb2e79ebeed8
Uploading to network:osmocom:* should only be done when these scripts
are running in the Osmocom jenkins. Remove the default and require users
of the script to explicitly set PROJ.
Related: SYS#5370
Change-Id: If49ce217e77716b63dfde9139e869672a54b66a2
Instead of only appending the date to non-Osmocom packages in
get_commit_version, append it to all packages in build(). This ensures
we increase the version of Osmocom packages even if the commit did not
change.
Fixes: OS#5135
Change-Id: I04d84f39f4093c8edfe21a94c10ecb8d3c7b5b64
Skip the logic to generate a new debian/changelog version for
osmocom-nightly and osmocom-next packages in build(). Use
$OSMO_OBS_CONFLICT_PKGVER instead, as it gets written to
debian/changelog in common-obs-conflict.sh already, and append the date
to the variable.
Related: OS#5135
Change-Id: I85f0bcb633c16c7b5a81104f198d9561f53c0c01
Depending on the service, error messages are not shown with the
systemctl command. Run journalctl for failed services so we get the
reason for the failure in the jenkins log.
Related: OS#5130
Change-Id: Ib454424d7867137246fadd73255d4dbff63731a6
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
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
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
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
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
Prepare for future conflicts test, which will configure repositories
with a different PROJ.
Related: OS#4733
Change-Id: Ib9946b5a02f8692efc8515907ba84048026474f9
Download and add the release key for the debian repository from OBS.
This is useful for manually testing the existing tests with a different
PROJ for debugging, and it will be used by a future conflict test to
install a second repository (e.g. nightly and latest at the same time).
Note that this is not needed for rpm, because the dnf package manager
automatically downloads the key if it is missing.
Related: OS#4733
Change-Id: I91e7a208d8f5cb50f8baa2fde0eb979aae91da8f
Use $PROJ instead of $FEED in the repository name, so we can add $PROJ
as parameter to the repo configuration functions later without worrying
about having a matching $FEED.
Related: OS#4733
Change-Id: Ic316add6b2d9b6f50335cad762628bb16da61d82
Don't call the file osmocom-latest regardless of the feed name. This becomes
important in a future conflict test where we will have two repositories
from two feeds configured.
Related: OS#4733
Change-Id: I8926443a9ff70f285d9467d39658e64456972b07
Move the two debian-specific variables to the debian-related functions
where they are used. Both are only used once, and having them global is
misleading since the test isn't just for debian anymore, but also for
centos8.
Make the variables lowercase to indicate that they aren't used globally.
Related: OS#4733
Change-Id: I1dfddbd9311d741c03ceedb12aee9aeae6abdab8
Make debugging easier by having a PROJ variable that can be overridden
by an environment variable of the same name. Pass it to docker and use
it to generate all related URLs etc.
Add functions in run-inside-docker.sh to convert the PROJ variable into
the two other formates needed (with slashes, with underscore), so a
future patch can use these functions with a different PROJ variable too.
Related: OS#4733
Change-Id: I0ac05a79ad65b5664b5ba37227b65e3b1422a4bf
Create a rpmlint config, which makes the shlib-fixed-dependency check
non-fatal, as it caused builds for openSUSE_Leap_15.2 to fail. The check
is supposed to warn about libraries depending on specific versions of
other packages. However, for the nightly and next packages, this is
exactly what we want to do to ensure that users will always upgrade all
Osmocom packages to the builds from a specific day, and not mix them.
Messages from the check:
[ 307s] libosmocodec0.armv7hl: E: shlib-fixed-dependency (Badness: 440) osmocom-nightly = 1.0.0.202101181006
...
[ 307s] libosmovty4.armv7hl: E: shlib-fixed-dependency (Badness: 440) osmocom-nightly = 1.0.0.202101181006
[ 307s] Your shared library package requires a fixed version of another package. The
[ 307s] intention of the Shared Library Policy is to allow parallel installation of
[ 307s] multiple versions of the same shared library, hard dependencies likely make
[ 307s] that impossible. Please remove this dependency and instead move it to the
[ 307s] runtime uses of your library.
[ 307s]
[ 307s] (none): E: badness 3960 exceeds threshold 1000, aborting.
Related: OS#4733
Related: https://en.opensuse.org/openSUSE:Packaging_checks#Disarming_Fatal_Errors
Change-Id: I560b4adf80b5785d396a17afefa590559ad5ca5a
Now that we have the proper fix of making a clone of
osmo-gsm-manuals.git available before builds start, and not using
'osmo-build-dep.sh osmo-gsm-manuals' in the contrib/jenkins.sh files
anymore, we can remove the temporary solution. This reverts commit
4cbc445616.
Related: OS#4912
Depends: https://gerrit.osmocom.org/q/topic:jenkins-no-manuals-dep
Change-Id: I88d57ee04775dc75e6ca3152d7edfa7f47608c8a
Make sure that each time osmocom-nightly-packages.sh and
osmocom-next-packages.sh runs, we get a different date appended to the
versions, even if it runs twice on the same day (e.g. because the
jenkins job was triggered manually).
This is in preparation to let all packages depend on a specific version
(with that date) of the conflicting dummy package.
DT in osmocom-latest-packages.sh is adjusted for consistency (though it
is not appended to the package versions, only used in the commit message
when pushing the latest packages).
Related: OS#4733
Change-Id: I7f08c694a549f1b3dd938a68e05082f2c31fdb92
Rename $spec to $spec_in and add $spec to hold the destination path, to
avoid constructing it multiple times below.
Related: OS#4733
Change-Id: I4f3d4f8a8bc83ff22983e49f6a496dc8318b53cd
Check if we are trying to make a package depend on itself, and skip in
that case. This happens for the osmocom-nightly etc. metapackages, as
they go through the same code path as regular packages. While at it, use
proper variable names in the function.
Add the new variable as second argument and not as third, because a
fourth argument will be added with the dependency version, and because
this order will be consistent with osmo_obs_add_rpm_spec() when it gets
extended in a future commit.
Fix the following warning:
W: osmocom-nightly source: package-depends-on-itself osmocom-nightly depends
Related: OS#4733
Change-Id: I439079c00259d73a18cb8617a3e76d05df5a7a35
Change name to osmo_obs_add_depend_deb. I'll add a _rpm function in a
future patch, and so we get consistent names.
Related: OS#4733
Change-Id: Icf444b86df993184c9fe4db8d3e67ab4bb06bd47
Move logic to create the package directory, change into it, and to put
the directory into a git repository and tag it with the package version,
into the common function. Again, in preparation to add a _rpm function.
Related: OS#4733
Change-Id: I3066147ef5469cce9d269b119d9ffa3e53f00403
Prepare to move the 'put in git repository' code from _deb to the main
function by having the pkgver available outside of the _deb function.
Change the version to 1.0.0 while at it, as it looks better than 0.0.0.
Related: OS#4733
Change-Id: Ic56ff12b5f2fe596d73b341e1e7750a9e202ed6b
Prepare to add the _rpm function by moving the debian code to its own
function and tweaking the comment above the function.
Related: OS#4733
Change-Id: Ic8d55c432c6035e7ac855cf6869d2c86ace468df
Prepare to add another function that creates similar dummy packages for
rpm (current version only works for deb).
Related: OS#4733
Change-Id: I29a5f54fe3a09610cffa0eacb5f0ad99154612f7
Save time by only cloning the repository, and not running autoreconf
-fi, ./configure, make and make install. Especially the tests during
make took up significant time, that slowed every project depending on
osmo-gsm-manuals down while being built through master-builds or
gerrit-verifications jobs. Set OSMO_GSM_MANUALS_DIR to the clone
location.
This is an interim measure, I'll submit more patches soon that remove
the 'osmo-build-dep.sh osmo-gsm-manuals' calls from all projects.
Change-Id: I5238cf3f93ded97ed2b44d27868123a646e122dc
Related: OS#4912
We use centos8 instead of centos in all docker-playground.git setups and
the infrastructure there expects that kind of naming.
Related: OS#4888
Change-Id: Idfbb2c4fc1ca10741406c8ab8930dabe8ce632ee
Some unit tests in those repositories started failing due to a fix in
libosmocore logging system where extra coloring tags were printed when not
needed.
Unit tests in current master of those repositories are fixed to work with
both old and new versions of libosmocore since they got coloring disabled
in their output, and new patch releases have been done containing the
fix, which means last releases already work with both libosmocore
version. However, older releases are expected to fail when built against
libosmocore master.
Change-Id: I03ca926b903a4dcc9967ab5fe455d715cdb9ed45
This reverts commit e17a4d66d0, i.e.
we are back to building the latest tag, now that v20.07.1 has been
released, which actually builds again.
However, the package name in debian/changelog has not been updated to
reflect that version change, resulting in v20.07.1 being packaged
in a package called v20.07.0.
Change-Id: I01b77f03924a0b303103fb737dfee15b9c4b0c9c
See https://github.com/myriadrf/LimeSuite/issues/313
This also reverts the previous commits that removed the work-around for
building LimeSuite on Debian10, as that one is still required for
v20.01.0 (and not for v20.07.0).
Change-Id: Ib70418f0b8a4c6aafa3098b6fa3e240f89112b59
The only part that we haven't migrated elsewhere is osmo-bsc_nat,
which is also really unmaintained at this point. Let's not confuse
people into thinking they should actually use this software anymore.
Change-Id: Icee165422a52bfe04be103a5b7ebb5c8909c0321
common.sh tries to set OSMO_CI_DIR now; however this does not work when
common.sh was sourced with ". ./common.sh":
realpath: scripts/..: No such file or directory
Fixes: 7cb8e2d0 ("OBS: add debian10 specific patch for limesuite")
Related: https://jenkins.osmocom.org/jenkins/job/Osmocom-build-tags-against-master/455/console
Change-Id: Ib326eb0fa769528398335c9cf06dc9c9576c882e
Fill the "next" feed with source packages generated from the "next"
branch of each Osmocom project, if it exists, with fallback to the
"master" branch. Implement as wrapper around osmocom-nightly-packages.sh,
so we don't duplicate code and don't need to add more logic to the jenkins
job.
Adjust all osmo_obs_prepare_conflict calls. Add a comment line on top of
each osmocom-*-packages.sh script stating the feed they can be used with.
Related: SYS#4887
Change-Id: I0542b6243bdd29d08381fcc82368dcbd30bf9dce
For the upcoming network:osmocom:next repository, it would be
inconsistent to have the debian package conflict mechanism only support
latest and nightly, even if the next repository is currently not built
for debian.
Change-Id: I2c07313fbbdffe5571e447059b08fe74c853cef0
The "run-inside-docker.sh" script is running as root (in order to be
able to install packages). Do not mount an outside directory as /data
inside the image anymore, where the script would write temporary data.
This causes problems on jenkins, as the temporary files are written as
root and jenkins is then unable to wipe the workspace.
I had used this for debugging when I wrote the script initially, but
almost the same can be done now with INTERACTIVE=1 and cat on the
temporary files.
Related: OS#4563
Change-Id: If7e1d83580c2951e7e50181ba7e755b987675e4b
Keep downloaded binary packages to make test cycles shorter during
development. While at it, also document all environment variables.
Change-Id: I4d6ebaf460e47f29e023acb0bd78ef52ca80c7cd
Make it consistent with run-inside-docker.sh by also using -e and -x.
This makes development easier.
Change-Id: I733164829bf076fb42df3fde725f3e330f8abecc
Make the script work on a debian10 host. I had developed it initially on
debian9, where this was not necessary, and the Jenkins servers are also
running debian9. Fixes:
Failed to mount tmpfs at /run/lock: Permission denied
[!!!!!!] Failed to mount API filesystems, freezing.
Freezing execution.
Change-Id: I5127356031a5dd080473aa650c2beae2a81a697f
Prepare the repo-install-test to be extended to cover centos8 as well.
Move the scripts to osmo-ci.git first, so we can mount them as shared
files into the docker containers from here.
Move files without any changes. Integration will be done in a follow-up
commit, so we have a clean git log.
debian-repo-install-test/jenkins.sh
=> scripts/repo-install-test.sh
debian-repo-install-test/testdata/blacklist.txt
=> scripts/repo-install-test/blacklist.txt
debian-repo-install-test/testdata/repo-install-test.sh
=> scripts/repo-install-test/run-inside-docker.sh
Related: OS#4563
Related: If93f37e8d46597a9abc67a4529be9addd65780f5 (docker-playground)
Change-Id: Ia678cc15e66630bd6b75b6c89bc75c1e27afd66c
The list is incomplete, and we have a programmatic check for required
binaries in common-obs.sh now. The next patch will add a new one of
these scripts, so let's clean it up a bit.
Change-Id: Ifab635e0d7a162142a8e80f3223d024888114f3f
Add a patch to replace libwxgtk3.0-dev with libwxgtk3.0-gtk3-dev in
debian/control. Adjust OBS scripts to apply such patches from this
repository if they exist here, and fall back to the project's
repository (osmo-trx, osmo-gsm-manuals patches are there).
Related: OS#4562
Change-Id: I8dfb60e999bf9f61e6cd11983dba033a4c6107ad
Refactor checkout_copy_debian8_jessie from osmocom-latest-packages.sh
and osmocom-nightly-packages.sh to take the distribution name as
argument and merge both to osmo_obs_checkout_copy in common-obs.sh.
Use debian8 as distribution name instead of debian8-jessie, so the
distribution name matches the suffix of the patch file
(build-for-debian8.patch).
A follow-up commit will apply a debian10 specific patch with this new
function.
Related: OS#4562
Change-Id: I2b69571ebc08a920c9147ce544fa8a2e6d950e65
Prevent the following error:
ERROR: please install obs-service-format_spec_file or use the --noservice option
Build step 'Execute shell' marked build as failure
Related: https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/976/console
Change-Id: Ib2fbaace47b3c12462860419f19b01a5b4d192e8
osmocom-*-packages.sh take some time to execute and has quite a few
programs that are not commonly installed. Check the required
dependencies first, so it doesn't abort in the middle of the scripts if
these are missing. I just ran into this with the new meson dependency.
Change-Id: I46cf1aeedd61dbd4fc8fa3f24c60e29033339ead
sdcc does not build for centos 8 without diving deeper into the
dependency hell:
nothing provides gputils,
nothing provides python3-base,
nothing provides inkscape,
nothing provides lyx,
nothing provides makeinfo
So let's not build libusrp for centos 8 for now. We can build osmo-trx
without the usrp1 backend (already configured in the spec.in file).
Related: OS#4550
Change-Id: Icfb289b0eeeb7215d23517fb8a4e56f2a8d774f1
Use existing osmocom-*-packages.sh scripts to add RPM spec.in files. Set
the same version, as in the debian .dsc files.
Related: OS#4550
Change-Id: If93b9d95e4c18cf1c29594c0802cbffaea27101c
Let's use the osmo-gsm-tester docker image based on the
debian-stretch-jenkins instead of the later directly, since the former
has all osmo-gsm-tester required dependencies.
Change-Id: I256eeed82eef0969d93dc015e043b0417f56f52c
It's been noted that jenkins job update-osmo-ci-on-slaves succeeds even
if make script called by some children function fails:
"""
../make/Makefile:57: recipe for target 'docker-build' failed
make: *** [docker-build] Terminated
make: Leaving directory '/home/osmocom-build/osmo-ci/_docker_playground/debian-stretch-jenkins'
+ exit 1
Finished: SUCCESS
"""
Change-Id: Iab9bc49eebee0f42657ff3ab5ffaa10315446440
This is unfortunately harder than expected. The problem is the use
of meson external dependencies using 'wrap', specifically for
freeDiameter.
As a debian source package needs to include the entire source, the
dpkg helpers are calling 'meson --wrap-mode=nodownload' at build time.
This in turn requires us to download the freeDiameter after the git
clone of open5gs. Unfortunately this creates a git checkout in a
sub directory of the open5gs repo, which is not part of the git history.
git-buildpackage hence generates a source tarball *without*
freeDiameter. I tried very hard in several methods like
* git commit subprojects/freeDiameter
* adding subprojects/freeDiameter as git submodule
unfortuantely none of them helped.
In the end, I resorted to using 'dpkg-buildpackage' instead of
'git-buildpackage' (gbp), which then has other disadvantages,
such as not being able to determine the output directory to which
the .tar.* and .dsc files are written to.
In the end, the solution implemented here is the only one I could
make work.
Change-Id: I6752288868e5ee1378c0776b1be9f06750017c41
Work around "garbage at end of loose object" errors that occasionally
cause these jenkins jobs to fail.
A few repositories are not hosted on gerrit, so they still get cloned
from git.osmocom.org. However, having almost all repositories cloned from
gerrit should improve the situation a lot.
Related: OS#4083
Change-Id: Id8f08a1bc10d6c81be9ad44c60646e2ea9f6cf4e
Run contrib/jenkins.sh in erlang repositories, that were recently
updated (osmo_gsup, osmo_dia2gsup, osmo_ss7).
Depends: docker-playground Ia3eaec6090c9652549b2850de74ee21730374bbd
Related: OS#4345
Change-Id: I05d152de6b7a04dee935d79b9987c511351eca95
Instead of building "osmocom:deb9_amd64" from this repository, build
"$USER/debian-stretch-jenkins" from docker-playground.git (same
Dockerfile). Adjust all jobs to use the new image name.
Add a new "update-osmo-ci-on-slaves-dp" jenkins job, which triggers
the existing "update-osmo-ci-on-slaves" job whenever
docker-playground.git changes.
Replace docker/rebuild_osmocom_jenkins_image.sh with
scripts/osmo-ci-docker-rebuild.sh, so we can get rid of the docker dir.
I thought about dropping the script completely, and directly writing the
two lines into contrib/jenkins.sh. But I kept the extra script for
convenience, when testing locally.
Related: OS#4345
Depends: docker-playground I125ae8a6bcabbd1f485028c79b0abacda0622c3a
Change-Id: I30a61aebcadef5536e74edd35e1c75ef77a2da9f
Make development easier by skipping fetch, checkout and reset --hard if
_docker_playground is a symlink. Document _docker_playground in
README.adoc and explain how to set up the symlink.
Change-Id: If6209ff71488d39e590f5f8506b9d73ad0314846
This is a problem e.g. with current osmo-hlr containing
"\t# FIXME: PKG_CHECK_MODULES() may return cached result here!"
Change-Id: I30d539a895bf39aaabe907be9eb52d7e4b3977a7
Some of our source files are inherited from other sources, particularly
for microcontroller firmware projects. We cannot assume they're all
clean UTF-8. Let's ignore any decoder errors when verifying log
statements and value_string arrays.
Closes: OS#4334
Change-Id: I1e19f4bc6bee46481c6ea743e8334bd4485909be
Do not set LD_LIBRARY_PATH during builds, as this causes testsuites to
use the wrong libraries.
This bug appeared with libosmocore, it gets built for master first, and
then an old version like 1.2.0. When using LD_LIBRARY_PATH, the tests
during the 1.2.0 build are executed against the libosmo*.so from
master, which causes a few tests to fail.
Change-Id: I0bfb57e418b91c298337b9426448fbcfd7bf32e6
The OBS job clones a lot of repositories from git.osmocom.org every
night, so it is a good candidate to reproduce the "garbage at end of
loose object" error we are getting sporadically.
Print exact timestamps, so we can check if there is anything related in
the server logs, when this error happens again.
Related: OS#4083
Change-Id: Ic9a6d3f0c2b8dad2661ede793c21307f1680a52e
Clone docker-playground.git, source its jenkins-common.sh and run
docker_images_require from there. This will make it possible to run
osmocom-release-tarballs.sh in a docker container, for which the
Dockerfile is stored in docker-playground.git.
Related: OS#3870
Change-Id: Ic4519ccb6978793054869862f8ca0e21d9cf5be4
Add conflicting dummy packages osmocom-nightly and osmocom-latest, and
make all packages from each repository depend on the right one.
As usually, the latest packages will only get changed when a new release
appears. So the dependency will get introduced after tagging a new
release. I have tested in an own OBS namespace, that everything works as
expected.
Related: OS#2640
Change-Id: I79c45e798c10a65443b9fb9ecb54393d1918608a
Enable in osmocom-latest-packages.sh. Check it out and create the source
package for the latest release as usually, but also create a second
version for debian 8 with adjusted dependencies (like in nightly [1]).
[1] Change-Id: I3570599ede51b974d350064f44f77e360fafd8b0
Related: OS#3899
Change-Id: Ib7251cca9116151e473798879375cd5eb48ff3ad
Since libosmocore 1.1.0 and libosmo-netif 0.5.0 are released, we can
address the TODO and build osmo-sysmon also in our latest feed.
Change-Id: I48bd5aff2ae315b6f462facea70222eb2cdd2d58
Create a compatible package for debian 8 with adjusted dependencies.
While at it, refactor create_osmo_trx_debian8_jessie() into a generic
checkout_copy_debian8_jessie() function.
Related: OS#3899
Depends: I5b9575ceb1141961e570643a5755a2bd6b6a4254 (osmo-gsm-manuals)
Change-Id: I3570599ede51b974d350064f44f77e360fafd8b0
Newer LimeSuite (at least 7557e291209fc66a78ffa74dd8314e75841f7c96) is
required to have LimeNet-Micro working properly with osmo-trx.
We update to current newest master since other fixes related to sample
rate are applied after the commit mentioned above.
Related: OS#3861
Change-Id: I62779f3bdbc4a459363a1d660d96d5f02f7763c1
Enable in osmo-nightly-packages.sh, and add as coment in
osmocom-nightly-packages.sh for now (needs a tagged release first).
Related: OS#3899
Depends: I7edb5093e5b58eb3b0f7af2376476db4026db735 (osmo-gsm-manuals.git)
Change-Id: Ideeae4f7846fa5626fe2c1f5a77e07a3c6e626fe
As of Change-Id Id5044b1835190edc948952d207a5196a18669eb1, osmo-remsim
contains Debian packaging information and hence we can build it as part
of our nightly feeds.
We're not yet enabling 'latest' builds as we need to wait for the next
libosmo-abis release for that (requires the IPA keepalive FSM).
Change-Id: Ic367dc95f46cece4bd769061af860fd82b4bd2e9
Build osmo-mgw 1.4.0 (which provides libosmo-legacy-mgcp) and install
it into a different temp dir. Allows properly building osmo-bsc 1.2.x,
as soon as a new release is tagged, which makes it use
LIBOSMOLEGACYMGCP_CFLAGS and therefore pick up the include path
properly [1].
osmo-mgw 1.4.0's "make check" doesn't pass right now, so add a check
parameter to build_repo() and disable them when building
libosmo-legacy-mgcp. The checks will get executed later, when the
depends are installed and we are building various tags of Osmocom repos,
including osmo-mgw 1.4.0.
While at it, slightly refactor build_repo() to put all arguments into
descriptive variable names (as it is getting a bit longer now).
[1]: Change-Id: Ibd7948f12da710f8ca2b8fde8870f134308eb908
Related: OS#3867
Change-Id: I63d16f8e44c14dee46e2ef3fd050a421017c56b0
Build old releases of Osmocom programs and libraries against
"master of the day" to detect breakage.
Redirect each build's output to its own log file, so it is easy to see
what is currently getting build, and what failed. On error, print the
end of the new failing build logs, along with a note to find the full
logs in the jenkins artifacts.
This initial configuration builds the last three release tags of the
Osmocom repositories against master. The configuration can be changed
easily.
Indicate known failures with "err" instead of "ERR" in the output, do
not cause them to fail the build and do not print the beginning of the
error log (it is still in the artifacts). This way, new errors stand out
and don't get overlooked among the known errors.
Related: OS#3765
Change-Id: I7cb45cc40c9930840a3d4e6a86f39e1400478ed3
Support building the legacy openbsc source with osmo-build.dep.sh. This
will be used by the upcoming osmocom-build-old-tags-against-master.sh
script.
Related: OS#3765
Change-Id: I852e103e80bf295f692cf13c4cb38e80fbc19eca
Prepare for the upcoming osmocom-build-old-tags-against-master.sh
script, which will benefit from querying the last n git tags in advance.
Related: OS#3765
Change-Id: I61be4cffb9275cabc1b253f0b298503ad0d3aea4
Properly sort "git ls-remote" output, which looks like:
352f32c9cffef2e5df99cd2f03368dc56c99ee23 refs/tags/0.4.0
Use / as field separator and field no 3, instead of assuming that the
string gets split automatically after the tab character (which it does
not).
Use -V (version sort) instead of numeric sort.
Change-Id: I334e684ac5109fc289b68af78165862148074ea7
Generate a table of Osmocom CNI repositories and their latest tag,
related commit, and last commit on master.
Related: OS#3840
Change-Id: I91cab0139229e6c1c67e889d33b3d984025bc9da
Now that libosmo-dsp has a 0.4.0 tag that includes debian packaging
information, we can add it to the latest feed.
Change-Id: Ic082a4ad6b8582dfe44df5bdaafa525e52da7246
this is an ugly workaround for Jenkins not being able to deal with slash
('/') in label names that comprise the axis of a matrix buildjob, while
nuran not using tags but only branch names in their firmware
repositories :(
Change-Id: I1bbfc61f66c5fc490ceca96a8eb21210dd89b629
This way the latest script is a lot more similar to the nightly one, and
easier to maintain and expand with new features.
checkout and build steps are split because once we have a new
osmo-trx release, we'll need the create_osmo_trx_debian8_jessie trick to
build it.
In the future we can do further steps to have a common function lib
between latest and nightly scripts.
Change-Id: I786c6f4ad4b4e43d1692c1588d2ad2194d0b25a4
* replace --gitdir with --workdir and give it a new folder structure:
* git/$repo: downloaded source code
* build/$repo: files created during the build process
* install/: installation prefix
* adjust the jenkins job to use --workdir
* fetch --tags when source exists already
* readable error message for failed git checkout
Change-Id: I06589277b9d54a2af177451cfab2ca1a658b4058
Relates: OS#2642
This script verifies that Osomcom programs really build with the
dependency versions they claim to support in configure.ac. In order to
do that, it clones the dependency repositories if they don't exist
already, and checks out the minimum version tag. This happens
recursively for their dependencies as well. See 'osmo-depcheck.py -h'
for the full usage instructions.
There's also a new jenkins job in jobs/osmocom-depcheck.yml.
Change-Id: I8f495dbe030775f66ac125e60ded95c5d7660b65
Relates: OS#2642
A compatible package for debian8 as it does not support limesdr.
This patch depend on: I261302d2ed16e76540073589504e7426e23d00a1
Change-Id: I8477b580976b376ee5abdde98a651d47199ef6d9
We're using the build() function not only to build osmocom projects
requiring a .tarball-version file, but also other projects such as
libusrp. Let's make the related git-buildpackage arguments conditional
to whether or not a .tarball-version file exists at all.
Change-Id: I0683cff036a240b1b819f91fbd230d5f9211074c
We're using the build() function not only to build osmocom projects
requiring a .tarball-version file, but also other projects such as
libusrp. Let's make the related git-buildpackage arguments conditional
to whether or not a .tarball-version file exists at all.
Change-Id: I0312a6671e739b803beb583769e4dfc6f44fa091
If a new package is uploaded to OBS, prior to this change,
only the .dsc file is uploaded, not the actual .tar.xz containing
the source code. Let's fix that.
Change-Id: Id1c9e6d112781004238a516b24dd446af0beb95a
At the "autorecon -fi" stage, Osmocom programs either need the .git
directory peresent, or a .tarball-version file in order to determine
the exact source code version.
Normally, "make dist" exists exactly for this purpose: It runs
git-version-gen and saves the result to .tarball-version, and we then
include this file in the .tar.gz we generate.
However, as the nightly paackaging scripts use git-buildpackage, it
bypasses the "make dist" logic and hence we need to
1) manually generate the .tarball-version file
2) copy it over to the directory specified as --git-export-dir
This way, the .tarball-version is inside the tar.xz generated by gbp,
and autoreconf then has something to use as PACKAGE_VERSION.
This commit fixes "UNKNOWN-dirty" in .pc files of libraries, as well
as in "show version" commands on the vty.
Closes: OS#3449
Change-Id: I76e3713f0b01a6110091ff90e8e53aa79533c374
If string eval encounters an uncovered parse error, it's useful to know which
file it happened in.
Change-Id: I5fe9a3bbdbfb8a995f24596bf09e70ca5bb3fe8a
This came up in
https://gerrit.osmocom.org/#/c/osmo-bsc/+/9671/6//COMMIT_MSG@36
The errors it finds in the current code base are numerous, and many are
intended LOGP .. LOGPC calls. It doesn't make sense to enforce this, but so far
this can be used manually.
Change-Id: Id79389f090a2fded7ff01dc7e3fe9774e7f22ca0
So far we call with a $(find . -name "*.[hc]") argument list, which might
become too long at some point. Rather include dir walking in the script itself
and allow passing dir arguments as well.
This is backwards compatible, calling with above file args still works.
Change-Id: I36456383906b6295c798b82aa131dda21f8efc02
osmo-trx-lms requires limesuite newer than 17.02, as there were a lot of
features and bug fixes which osmo-trx relies on. Furthermore,
osmo-trx-lms cannot build with that version since it doesn't provide
yet a pkgconfig file.
We cannot use latest tagged release (18.06) since that version has some
build related bugs which have been fixed later on
(c1496679cadff2913cacdaa84afe93bbee76d8e4), hence why we are using
latest available master instead.
Change-Id: If47a3767c7fefbb75923cbfc8eeb921e29393285
Let's move limesuite first since it doesn't depend itself on any osmocom
related package, and osmo-trx depends on it.
Change-Id: I0cdc85a2d0212432bf0c2586230660d363212dcc
Writing '{ 0, NULL }' is actually identical to just '{}', and that's what I use
these days in all sorts of other contexts. So allow this notation as well in
the C code grepper.
Change-Id: I0822d2d997dccbfb31316953a7b6024c317d92cf
This reverts commit 5b2bb86e8a.
While it was intended to enable automatic "latest" builds from rtl-sdr,
it breaks builds e.g. of libosmo-abis, where we have both (new) tags
without 'v' and old tags with 'v', and now the older 'v' tags win
due to lexicographical sorting :(
Change-Id: I1c8d2ab18e389a8c2c41082d997f101d72c3acc0
we cannot yet build "latest" for them, as they don't have any tagged
versions yet which include the /debian directory.
Change-Id: Ia5708508d918fd71eb05393e39b93859b943d623
Some projects (notably rtl-sdr) use "v" in front of their version
tags in the git history. Let's make sure we also recognize those.
Change-Id: I20f9896cc7844a6ddec7ba63bc9a77f548082e2a
Now that osmo-fl2k has debian packaging information included, we can
easily build it as part of the "latest" and "nightly" feeds.
Change-Id: Ie2429df14ad51aadb55b4a7d8f6cfcb45c5c6e70
Now that rtl-sdr has debian packaging information included, we can
easily build it as part of the "latest" and "nightly" feeds.
Change-Id: Idc6afb523e71ed977401d707895844bad6247f8b
E.g. old version 0.10.2.20180501 (0.10.2 last deb version,
20180501 was the date)
The new version will look like 0.10.2.279.178b
- 0.10.2 is the last tag
- .279 is 279 commits since the tag
- 178b is the actual short git rev
The direct output of ./git-version-gen couldn't be used because
debian forbids using a minus (-) in upstream versions.
Change-Id: I2da90ada90adf8ef8f8cfee3d26f86fbd3cec181
This script should be executed regularly on all build slaves that
have docker in order to discard unused images/layers. It would
be a good idea to call "fstrim /" afterwards in order to get more
SSD performance. However, the latter requires root access, and hence
cannot be called by the 'osmocom-build' user and thus jenkins.
Maybe we should install it as a cron job or systemd periodic timer job?
Related: OS#3144
Change-Id: I688b952578507a9cc28fe682221b5c7e3a245519
git clean always excludes git clone subdirs; furthermore, even if I supply a
dir as -e, the contents of that dir still get cleaned out. So it is useless to
pass -e on the commandline. Drop it.
Change-Id: I2b59cc9c9adf88a2663469b22cfeffbd66b5bf2e
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
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 split build script also initilize the repository if it's empty and doesn't
need any state of the osc repository.
It also downloads bumpversion and limesuite
Change-Id: I3b55e14b5b4915a3aae23ee382d65bce4ef82774
Using a $TOP variable makes directory paths more clear
to understandable. Path now expressed starting from the TOP dir
instead of using ../../../foo
Change-Id: I7a87532a3232fbcfb5f676588991dbc59a34f739
It was recently spotted, in a osmo-msc jenkins build, that an updated
dependency (new commits to be fetched) contained a new tag which was
not fetched with the commit. It resulted in the Makefile generating an
old .version file, which ended up generating a library version in the
.pc which later in the build make the configure script fail while
checking at the dependencies.
As far as I could understand after reading several discussion threads,
it seems git fetch doesn't necessarily fetch and store locally all new
tags found in the remote, and we need to explicitly add the --tags
parameter to be sure all of them are downloaded.
This patch adds a new fetch line instead of patching the one already
present because it seems in old versions of git the --tags parameter had
a different behaviour, in which only tags and not branches are fetched.
This way is ensured that we get both correct regardless of git version.
Change-Id: I4bfe4846959c70e435d6792a755a6f2a6f0a932c
If I have a git clone that once did 'checkout [-f] branch', and if then
origin/branch gets updates, doing another 'checkout -f branch' only goes back
to the local tracking-branch of origin/branch. We never pull in changes from
origin/branch anymore as soon as a local branch exists. Always prepend
'origin/', so that 'checkout -f' goes into detached-HEAD state onto the newest
fetched revision.
Change-Id: Ia715a100b5beaf7e612c2c64cdad8819aa00c8bd
libgtpnl is the userspace library for using kenrel GTP-U support,
which is used by openggsn (and will be used by osmo-ggsn).
Change-Id: Iad600a36cb658bbd874b4587ec514f49703d6a45
Make sure osmo-deps.sh passes no $deps in to osmo-clean-workspace.sh.
In most builds, $deps is a relative path, and when within a dir that contains
no such subir, calling osmo-clean-workspace.sh has no effect. However, in some,
$deps is passed in as absolute path, so when within a deps/... subdir in
osmo-deps.sh, the script would still find the abspath and clean out all deps
subdirs; for example in osmo-bts.
Change-Id: I431d20aedefc708645a1f1862334cffaef20b928
'checkout -f' more accurately does what is intended. 'reset' changes the
current branch to some hash, 'checkout -f' force-checkouts another branch.
Change-Id: Ic6279ebaf8160bceb3fa2ab40eff0b888ecd5009
In osmo-deps.sh, add second arg $branch, and also name the first one (i.e.
$project). Use the passed branch or 'origin/master' by default.
In osmo-build-dep.sh, it's not necessary to do a second 'git rev-parse HEAD',
osmo-deps.sh already does it.
Change-Id: I598c41a12352acea6e49a321ad2f665f6ea07a44
So far, each jenkins job does its own cleanup, more or less well. Also, jenkins
git config offers the 'Clean before checkout' option, which seems to fail when
there are non-writable leftovers from a failed 'make distcheck'.
Furthermore, our jenkins build slaves have unused compiled binaries piling up
by the gigabytes: each matrix build x each parallel build and each compiled
dependency therein builds .o, .a, .so and executables plus installs them to a
local prefix, and just leaves them sitting around to rot until the job runs
again. Instead, we want to clean them out when building is done.
All of this calls for a unified cleanup script that knows how to clean a
workspace properly, to run once before and once after each jenkins build.
Here it is.
Use that function in osmo-deps.sh instead of duplicating cleanup steps.
Change-Id: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
This was the last package that we only built in
osmocom:nitb-split:nightly, so we can remove the latter, too
Change-Id: Ib99e0775e9db30ec3c5263bb3a364d8cab4633c3
this package doesn't exist in the OBS anyway, yet we continue to attempt
to upload it there. Stop that :)
Change-Id: I0f0726ed412e4a281dcf99047ca22b494216b4ad
This is no longer needed by upstream osmo-bts since Change-Id
I9f004fb5c4c1db29d4792dfd281d388c7063da13
Change-Id: Ie53482a1538d1559e764da86dbbb78031c9c386b
For some strange reason, in commit
8e9fe08080, the osmocom:nitb-split:nightly
package feed was rendered to use old packages for sgsn+ggsn, rather than
current ones by removing the "osc upload" from this script, but still
leaving the packages in OBS at
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
Removing them half (only in osmo-ci but not at OBS) is a bad idea, as
it leaves people with old packages who actually want to use nightly
builds.
Also, removing the packages in general is a very bad idea. People
are *either* using osmocom:nightly, *or* they are using the
osmocom:nitb-split:nightly feed, but not both. So we cannot remove
any packages from the osmocom:nitb-split:nightly feed until we have
introduced all those packages to osmocom:nightly *and* we have given
people sufficient notice to update!
Change-Id: I5c091127d92a4b4beb7355e16abd9788fa3b9fe5
* use coverity check on osmo-ggsn instead of openggsn
* move osmo-sgsn and osmo-ggsn from nightly-split into nightly
Change-Id: Ia49969cbfb9ef57b635a3b5759f411f71a54f8e1
All jobs are in jobs/ directory and will be automatically verified and
deployed in a follow-up commit.
Note: osmocom-nightly-nitb-split.yml has been moved to jobs/ dir.
[1] https://docs.openstack.org/infra/jenkins-job-builder/
Change-Id: I04387367a6e2d737bfb50423c81a8908d3c2a89f
The script by Neels Hofmeyr <nhofmeyr@sysmocom.de> has actually nothing
to do with libosmocore itself - it's a generic build-time check used by
jenkins so it should be part of this repo to avoid extra checkout of
libosmocore just for this script.
Change-Id: I079218b61f512975ec5bfc7dc23503ec369cbb5a
jenkins job builder is a python library to write jenkins jobs in .yml or
.json including templating and basic substition operation.
To update the job call:
Create your own jenkins_jobs.ini based on the exmaple and call
jenkins-jobs --conf ./jenkins_jobs.ini update osmocom-nightly-nitb-split.yml
Change-Id: Ie7c655c6e0e3761e7970e479cadb5ae14faa2c1c
Basically, osmo-build.sh holds logic to check whether the necessary
artifact is available. If so it fetches artifact, unpacks it and
triggers the actual build. In case the necessary artifact is not
available osmo-build.sh simply builds all dependencies from source
by using osmo-build-dep.sh and archives deps to the ARTIFACT_STORE
afterwards.
The necessary functions to determine the artifact name from remote and
local repositories as well as the handling of artifact files live in
osmo-artifacts.sh, which is sourced by osmo-build.sh.
osmo-build.sh will be sourced by the contrib/jenkins.sh build script
inside each git repository. This automatically triggers the build,
so one need to source at the end of each jenkins.sh script.
See jenkins-openBsc.sh [1] for more details.
Artifacts will be stored as follows:
$ARTIFACT_STORE/$JOB_NAME/<dep_1>.<branch_1>.<rev_1>_...
..._<dep_n>.<tag_n>.tar.gz
Furthermore, ARTIFACT_STORE environment variable has to be set on all
jenkins slaves. The JOB_NAME variables is injected to each jenkins job
by jenkins.
[1] https://github.com/blobbsen/diy-artifacts/blob/master/jenkins-openBSC.sh
Change-Id: Ifee0a2f837d23b19aa5326f810234d5452e47484
Several of the supported BTS models require hw-specific L1 headers for
compilation which are stored in separate repository. Instead of
copy-pasting code which obtains those header for each BTS it's better to
create separate script.
Change-Id: I840533d5bf9233822bc0534a25c252f1cab0a7b0
Related: SYS#3682
Neels Hofmeyr
Pau Espin
Oliver Smith
Vadim Yanitskiy
Harald Welte
Alexander Couzens
Alexander Huemer