Skip to content

Code to parse gitlab hook for mrtests

Robert Andrew Currie requested to merge mrtests into master

This is an MR for the code which parses the output from gitlab hooks and signals that a main nightly build should run. (https://jenkins-lhcb-nightlies.web.cern.ch/job/nightly-builds/job/gitlab-mr)

This will be blocked by LHCbNightlyConf!185 (merged) as once this is in I will need to change the code here to reference scripts_version=master rather than scripts_version=mrtests.

This will also require a change to the jenkins configuration to not use the mrtests branch of this project after this has been merged.

How it works:

This MR parses the output from a gitlab webhook which delivers (via a 3rd party server) the 'content' of the command triggered against a gitlab project.

Particularly this looks for the following fields in the content from gitlab:

  • content['object_attributes']['note'] This is the comment the user wrote.
  • content['merge_request']['target_project_id'] This is the numerical id of the project the MR is from in gitlab.
  • content['merge_request']['iid'] This is the numerical id of the MR within the project.

The script then parses the content of the users comment and constructs a JSON object MR_TOKEN containing all of the relevant information from the user in a dictionary format.

The output from this is saved in 2 files (gitlab-mr-build.txt and gitlab-ref-build.txt) which are used to define environment variables and to trigger further main builds in Jenkins.

How it's used:

This code is the code responsible for parsing the output from the gitlab webhook which will have been fired by a user on an MR.

The commands which can be parsed here are:

  • /ci-test This performs a test of the MR comparing it to a reference build.
  • /ci-retest This re-runs the previous test which was launched against this MR.
  • /ci-retest-ref This will re-run the reference test build of this MR.
  • /ci-retest-mr This will re-run the test build corresponding to the latest code in the MR.

These commands are parsed such that any space separated words after the command and before the next newline character are parsed as options to be understood by this script. Commands don't have to be on a separate line to be parsed but it makes reading comments in gitlab easier if they are.

These commands also accept optional space separated arguments. An example of this use case is:

/ci-test LHCb!123 Rec!234 Brunel!456 Gaudi@877b5f0902410680313aff835640bd9477abd0fd platform=x86_64-centos7-gcc8-opt

  • This particular command will trigger a build which uses 3 MRs (LHCb!123, Rec!234 and Brunel!456). This is useful when code has to be touched across multiple projects.
  • This will also make sure that all of the builds checkout the Gaudi tag 877b5f0902410680313aff835640bd9477abd0fd.
  • And the reference and test builds will be constructed for the x86_64-centos7-gcc8-opt platform.

If optional arguments are passed to a test and then a re-test is requested afterwards these arguments are re-used and using the retest command saves having to re-issue a complex command again. Optional commands passed to retest will overload those send to the test command. Also if you can request a fresh test with no optional commands this will ignore previous optional build commands.

This is also part of https://its.cern.ch/jira/browse/LBCORE-1743

Edited by Robert Andrew Currie

Merge request reports