-
Notifications
You must be signed in to change notification settings - Fork 0
Run the Travis Docker container locally
There might be a few use cases where you need more information from Travis than the webpage provides you, or you need to debug something, or you want to build a release which takes longer than the time limit of 50 minutes for jobs. The following steps show you how to install, download, and run the Travis docker container you use on Travis CI.
First you need to install Docker itself. It might be in the package sources of your distribution already. Install it. If this is not the case, like on Debian 9 for example, follow step 1 of this guide.
Next you have to figure out which docker container is run with your jobs on Travis CI. For this check the online Travis build log. In the top part there's "Worker Information" which contains the instance: ... you're looking for. In the case of Ant it's "travisci/ci-garnet:packer-1512502276-986baf0". The part after the colon is the the tag. The image which runs is ci-garnet. To run it ourselves we need the newest instance. This can be found by looking at the available tags. In this case it's packer-1515445631-7dfb2e1.
Now that we have docker installed and now which image runs, we can deploy it locally by running
docker run --name build-travis-local -dit travisci/ci-garnet:packer-1515445631-7dfb2e1 /sbin/init
where the name can be chosen and is assigned to the running docker instance. If you do not belong to the docker group or you might not have sufficient permissions, you might need to execute the command with sudo.
This will download a bunch of stuff which will take some time. Maybe there will be some error shown in the end, but this doesn't affect the running docker container. To connect to the docker container, you need the name you chose earlier (and maybe sudo):
docker exec -it build-travis-local bash -l
Now you should be inside of the docker container. To change to the environment used online, run
su - travis
to change to the travis user, the usual mode found on Travis CI. Maybe you want to install some packages before you change to travis (you're root after changing into the container). This is typically found in the addons: apt: section of the .travis.yml configuration.
After you changed to the travis user, you might want to run the before_install: parts and set some environment variables. In the build scripts there's usually the check if there's a travis tag, otherwise the script is terminated. Remove this line since we do not have the tag, or set an arbitrary tag youself using export TRAVIS_TAG=some-tag.
You can also check what is run on Travis CI by checking the build log and look for entries with a time tag on the right.
As an example let's have a look at the ROOT 6 branch. You see that in before_install there are some commands to set up a build environment using CMake 3.13 and GCC 8.2:
source <(curl -SLs https://raw.githubusercontent.com/A2-Collaboration/travis-container-packets/cmake/setup_3.13.sh)
source <(curl -SLs https://raw.githubusercontent.com/A2-Collaboration/travis-container-packets/gcc/setup_8.2.sh)
Also numpy is installed locally (we do not have root permissions anymore now). You can export some variables to ensure gcc is used:
export TRAVIS_COMPILER=gcc
export CXX=g++
export CXX_FOR_BUILD=g++
export CC=gcc
export CC_FOR_BUILD=gcc
Now you can run the build scripts: ./build_cern-root.sh.
When the build script finished, you probably want to use the file somewhere else. To copy it from the docker container to your host system, you can use docker cp using a similar syntax like you might know from SSH:
docker cp build-travis-local:/home/travis/A2-Collaboration/cern-root6.tar.xz .
The first argument is the name of the docker container you chose above, followed by a colon and the absolute path of the file. And like the usual cp you need to specify where the file goes.
This seems a bit complicated to just compile something. The problem is that even a rather old stable Debian has more recent packages than the Ubuntu which is run in the container. One main problem will probably be that if you compile GCC on a system with let's say binutils 2.28 (still old), the linker might know and consider new features, which will lead to a different offset in the .text section of binaries. If the linker of the old Ubuntu (binutils 2.24) will link a binary using the new GCC linked with a newer ld version, it isn't aware of the changed offset and you will get an error message when linking is done for the first time like
unrecognized relocation (0x2a) in section `.text'