|Age||Commit message (Collapse)||Author||Files||Lines|
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.
Depends on: I5ff1d76f533b9ac68ab3f2c70ead6b66f4413b4f
It will otherwise not executed by the cron, because the cron
is checking for the executable bit
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?
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.
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
Some projects, like osmo-trx, may have tags created in a non-master
branch. Let's catch those too.
Tested with several osmocom repositories. The ones showing different
behaviour are osmo-trx (expected) and other repositories which have
wrong or no tags and are anyway not used since there's no OBS build for
Old cmdline is left of ==, new is right:
artwork: ( == )
asn1c: ( == )
docker-playground: (debian-jessie-buildslave-0.1.0 == )
layer1-api: (superfemto_v3.8.1 == )
libasn1c: (0.9.28 == 0.9.28)
libgtpnl: (1.1.0 == 1.1.0)
libosmo-abis: (0.4.0 == 0.4.0)
libosmocore: (0.10.2 == 0.10.2)
libosmo-netif: (0.1.1 == 0.1.1)
libosmo-sccp: (0.8.1 == 0.8.1)
libsmpp34: (1.12.0 == 1.12.0)
meta-telephony: ( == )
mncc-python: ( == )
octphy-2g-headers: (OCTSDR-OPENBSC-02.09.00-B1121 == )
openbsc: (1.0.0 == 1.0.0)
osmo-bsc: (1.1.2 == 1.1.2)
osmo-bts: (0.7.0 == 0.7.0)
osmo-ci: ( == )
osmocom-bb: (osmocon_v0.0.0 == )
osmo-ggsn: (1.1.0 == 1.1.0)
osmo-gsm-manuals: ( == v1)
osmo-gsm-tester: ( == 0.1)
osmo-gsm-tester-conf: ( == )
osmo-gsm-tester-sysmocom: ( == )
osmo-hlr: (0.1.0 == 0.1.0)
osmo-iuh: (0.2.0 == 0.2.0)
osmo-mgw: (1.2.0 == 1.2.0)
osmo-msc: (1.1.2 == 1.1.2)
osmo-pcu: (0.4.0 == 0.4.0)
osmo-python-tests: ( == )
osmo-sgsn: (1.2.0 == 1.2.0)
osmo-sip-connector: (1.1.0 == 1.1.0)
osmo-trx: (0.2.0 == 0.3.0)
pysim: ( == )
python-smpplib: ( == )
Instead of the subdirectory, the main repository was
forced checked out.
This commit introduces the usage of GNU stow for dependency
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
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
Stow has to be present on the jenkins build nodes for successful executing of
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
OBS should only be updated if there is a new tag.
Using a $TOP variable makes directory paths more clear
to understandable. Path now expressed starting from the TOP dir
instead of using ../../../foo
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.
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
libgtpnl is the userspace library for using kenrel GTP-U support,
which is used by openggsn (and will be used by osmo-ggsn).
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.
'checkout -f' more accurately does what is intended. 'reset' changes the
current branch to some hash, 'checkout -f' force-checkouts another branch.
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.
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.
This was the last package that we only built in
osmocom:nitb-split:nightly, so we can remove the latter, too
this package doesn't exist in the OBS anyway, yet we continue to attempt
to upload it there. Stop that :)
This is no longer needed by upstream osmo-bts since Change-Id
For some strange reason, in commit
8e9fe0808072d3f5eca8b4c6fac9865a52c9beb3, 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
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
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!
It produces libosmo-ranap-dev which is required by osmo-sgsn.
It depends on libgtp provided by OsmoGGSN so let's build it in that
* use coverity check on osmo-ggsn instead of openggsn
* move osmo-sgsn and osmo-ggsn from nightly-split into nightly
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.
Otherwise script depends on availability of https://git.osmocom.org, which is currently down.
The script by Neels Hofmeyr <email@example.com> 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.
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
Create a snapshot of the nitb split and upload it to OBS.
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
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  for more details.
Artifacts will be stored as follows:
Furthermore, ARTIFACT_STORE environment variable has to be set on all
jenkins slaves. The JOB_NAME variables is injected to each jenkins job
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.