Example trigger syntax
Put the trigger in a separate GitHub comment containing only the trigger line.
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
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.