Jenkins triggers

From opm
Jump to: navigation, search

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 ert=105 opm-common=103 please

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

For also triggering downstreams builds (that is, of modules that depend on the current one):

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

For opm-simulators and opm-data you can also triggger integration tests.

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

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 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 ert=105 opm-common=103 please" jenkins/

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-autodiff 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/