jgillis edited this page Oct 8, 2015 · 13 revisions

Layout of the continuous integration infrastructure.

Main tests

A first set of tests is in .travis.yml and appveyor.yml of casadi/casadi repo. These tests build, but do not publish stuff. The tests can however generate two types of commits: a code-generation commit and a documentation-generation commit.


A second set of tests is in casadi/binaries repo; each branch of that repo represents a logically grouped set of builds with the purpose of producing, uploading and testing binaries.

The glue that binds these together is twofold:

Both sets of tests depend on helper functionality from casadi/testbot and encrypted dependency builds from jgillis/restricted. The builds in jgillis/restricted, in turn, get built by the recipes in casadi/testbot.


Release can be triggered manually by pushing to the release branch of casadi/binaries (see e.g. release-2.4.0-rc3). Triggering will install all downloadable files created by casadi/binaries in the correct download location. This means all the files should be there i.e. the binaries built successfully. The triggering commit should have two changes: the version number in .travis.yml and the casadi reference in the submodule. Some subsequent actions are manual still:

  • merge to master
  • merge release to develop (usually only for x.y.0 releases)
  • bump develop to x.y.0+ AND tag that commit as "x.y.0+" (only for x.y.0 releases)
  • set default downloads on sourceforge

How to run travis locally?

  • sudo apt-get install
  • sudo usermod -aG docker myname
  • git clone
  • export PATH=$PATH:~/travis-run
  • got to the casadi source directory
  • travis-run create
  • travis-run