Support #3730

TTCN3 BTS real HW: create jenkins job to build and push ttcn3-bts-test docker image

Added by pespin 10 months ago. Updated 6 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


Right now, jenkins job calls osmo-gsm-tester.git/ttcn3/ which runs the ttcn3-bts-test container:

prepare_docker() {

        # update docker-playground and update the BSC and bsc-test containers (if needed)
        if [ ! -d "$DIR" ]; then
                mkdir -p ~/jenkins/ && cd ~/jenkins
                git clone git://
        cd $DIR
        git remote prune origin; git fetch; git checkout -f -B master origin/master
        cd $DIR/debian-stretch-titan && make
        docker pull laforge/debian-stretch-titan:latest # HACK
        cd $DIR/ttcn3-bts-test && make
        # execute the script to start containers, read results, ...
        #cd $DIR/ttcn3-bts-test && sh -x ./

However, so far I have being building and pushing the image to the docker repository manually. Since we usually introduce new tests and fixes, we need to have that done manually by some jenkins job.

These are the steps required to build it:

docker login -u "$MYUSER" # only once required

cd docker-playground.git/ttcn3-bts-test
docker build -t .
docker push

I have the credentials (user+password) to build it which can be applied to a jenkins node, but I'm unsure how to proceed to do this set up.

Which node should I use? How do I apply the credentials? I guess we don't want to run the "docker login" adding the credentials in some public place, rather do it once manually in the designated jenkins node. Are we pushing similar TTCN3 docker containers somewhere? how do we build and push them?


#1 Updated by pespin 10 months ago

[15:30:33] <pespin> You may know about how to do what I need here:
[16:10:04] <> I'll take a look at it
[16:15:56] <> I guess it's easier to chat about this than writing a wall of text in the issue.
[16:16:37] <> I know of two ways to build the docker containers, which we have implemented
[16:17:05] <> one is described here: - basically osmo-ci.git has a Dockerfile, and the container gets rebuilt whenever osmo-ci.git changes
[16:17:19] <> and the other one is for the ttcn3 tests. all of them get built on demand, without using a shared repo
[16:17:47] <> there's some caching magic in place, which makes Docker skip all steps where nothing has changed
[16:18:01] <> I'll explain with an example
[16:18:51] <>
[16:18:57] <> at the top, there is docker_images_require
[16:19:20] <> which is defined in
[16:19:48] <> basically it is always running "make" to build the docker container
[16:20:38] <> so in case of ttcn3-mgw-test, it depends among others on osmo-mgw-$IMAGE_SUFFIX
[16:21:38] <> so if that variable is master, it builds osmo-mgw-master, which is defined here:
[16:22:30] <> there are a lot of ADD statements, which are basically the rules when the "RUN" command above can be cached and when they need to be executed again
[16:23:33] <> so when the git repository did not get any new commits, it does not rebuild the software inside the container
[16:23:43] <> *the osmo-mgw.git repository
[16:24:24] <> ...and that's why we can run it every time, it goes through in a second, because everything is cached. and when it's not cached, it builds the container on demand. the container remains on the jenkins slave.
[16:24:59] <> that worked out well, now instead of writing a wall of text into the issue, I wrote it into this chat window. there you go :)
[16:29:25] <pespin> ok thanks
[16:29:30] <pespin> but in this case this cannot be used
[16:29:40] <> none of both methods?
[16:29:57] <pespin> because osmo-gsm-tester_run-prod job is run in OsmoGsmTester MainUnit
[16:30:11] <pespin> and we don't want to build docker containers (specially TTCN3 one) in there
[16:30:19] <> right, that makes sense
[16:30:28] <> but the other method could work
[16:30:29] <pespin> so we need to split building (and pushing) and using (and pulling)
[16:30:35] <pespin> the first one?
[16:30:41] <> yeah, maybe
[16:30:44] <> at least worth looking into
[16:31:03] <pespin> ok I'll have a look
[16:31:54] <> okay, it's also not suitable in that form for your case
[16:32:14] <> as I understand, it builds the image once on all build slaves, it does not push them to a server
[16:32:51] <> so for your case, you'd need a new job in master-builds.yml, with a that builds and publishes the docker image
[16:33:28] <pespin> yeah, but not sure how to do the credentials stuff
[16:34:08] <> right. you could use the sysmocom jenkins server, but I'm not sure if it can trigger on osmocom git repo changes
[16:35:54] <> with some basic research, the jenkins credentials thing seems to be able to store the credentials safely
[16:36:12] <>

#2 Updated by laforge 6 months ago

  • Assignee changed from laforge to pespin

We already appear to have a jenkins project "ttcn3-bts-test_docker-registry" at the sysmocmom jenkins which was setup by @pespin. Does this mean, the ticket is resolved?

#3 Updated by pespin 6 months ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)