Jenkins triggers

Example trigger syntax

Put the trigger in a separate GitHub comment containing only the trigger line.

General syntax:

jenkins build this module-name=<module pr number> please
jenkins build this libecl=105 opm-common=103 please

(Note that libecl is also allowed, in addition to OPM repos.)

By default, all downstream modules will also be built (that is, of modules that depend on the current one). This used to require a trigger of the following form (which is now unnecessary):

jenkins build this with downstreams libecl=105 opm-common=103 please

For all modules you can also triggger integration tests. This implies and includes "with downstreams" (in order to include opm-simulators which is necessary to run the tests for Flow) if the current module is not opm-simulators.

For running all integration tests:

jenkins run norne spe polymer please

For just running Norne:

jenkins run norne please

Run integration test, also with other-repo PR

jenkins run spe opm-core=974 please

By default, all tests are done with an MPI build. If you want to test a serial build in addition to a mpi enabled build, include 'serial' in the trigger phrase, for example:

jenkins run norne serial please

Troubleshooting

The Jenkins servers polls GitHub every 5 minutes. So if say 10 minutes pass without any build triggered something may have gone wrong. After reloading the GitHub web page to ensure that you are not looking at an outdated page, you can repeat the command (after first checking that it is correct), and it will usually work.

Automatic updating of regression test reference data

opm-simulators includes a set of regression tests which compare against reference files. You can generate a pull request in opm-data with updates for the reference files by including 'update_data' in the trigger phrase. This works for builds triggered from opm-simulators:

jenkins build this update_data please

or from builds triggered from other repositories. In the latter case it needs to used in combination with downstream building:

jenkins build this with downstreams update_data please

You can specify pull requests to use in the various repositories as normal.

Using the scripts locally

secondary but still useful: the scripts to run the jenkins jobs sit in git, and these can be used to execute the jobs locally on your machines as well.

you communicate the information usually obtained from jenkins through environment variables. the relevant environment variables are:

WORKSPACE = <root of source tree>
ghprbCommentBody = comment you normally would do on github.
sha1 = sha to use for context module. this is only a cosmetic thing, as build-pr.sh prints the used revisions at start. if omitted, you simply get a blank in a printed line but that is all.

so i could execute the example given above locally through

cd source/of/opm-parser
git checkout branch_i_want_to_test
WORKSPACE=`pwd` ghprbCommentBody="jenkins build this libecl=105 opm-common=103 please" jenkins/build-pr.sh

note that this will pollute the source tree so i recommend doing it in a throw-away clone. if you want to clean the source tree up afterwards you can do

git clean -xffd (double f is NOT a typo)

if you try to execute things twice in the same source tree without cleaning you will get failures.

the extra scripts for opm-simulators are intended to be run after the build script. you can execute them in the same way, but only WORKSPACE is then relevant, i.e.

WORKSPACE=`pwd` jenkins/run-spe.sh