Jenkins and Gerrit Trigger for the win

I had quite a few problems setting the workflow as follows:

  • I’d make a change in ansible files, and push them to a git behind Gerrit
  • Gerrit would trigger Jenkins with the new commit, and Jenkins would apply the linter on the committed files. If all is good, the files are send upstream to Rundeck that than picks the nodes from the inventory and plays the books, and Jenkins gives +1 Verify and +2 Code Review (yes, I want it to do all the job 🙂 and Gerrit merges the commit via a rebase always strategy; however, when linter marks the build as failed, it returns the -1 Verify and a “fail” for Code Review to Gerrit, and kicks no job on Rundeck until a build is fixed. Here started the problems…

JenkinsGerrit trigger page describes well what should be done with access for refs in Gerrit, but here’s the extra that makes all the difference:

  • in Gerrit Reporting Values in the trigger set-up, the following should be add for the fields:
    for Verify:
    – Started: 0
    – Successful: 1
    – Failed: -1
    – Unstable: 0
    – Not Built: -1

    for Code Review:
    – Started: 0
    – Successful: 1
    – Failed: -1
    – Unstable: 0
    – Not Built: -1

    for Gerrit Verified Commands, under Successful a –submit should be added in the line.
  • Enable Manual Trigger, and do not use REST API (using ssh here already)
  • Under the very job settings, in Source Code Management, for Refspec the following is required $GERRIT_REFSPEC:$GERRIT_REFSPEC and under Branches to build $GERRIT_REFSPEC because this will assure that Jenkins picks the amended commit, and not one commit after the last known commit to be good; if not set like this, Jenkins will keep pulling the main suspect for the broken build and keep trying to use it to produce a fixed build. Lovely, eh.
  • In Gerrit Trigger in the very job settings, under Advanced >> Code Review >> Successful a 2 is desired, because we want Jenkins and Gerrit to do all the job of the code review for us. Trigger this on Patchset Created and Draft Published, excluding all cases of changes for patchset creation. The pattern is of a plain type and it is your repo, and the branches are of a type path with ** as the option.
  • Delete the environment before the build starts.
  • Under Build the whole show takes place, it is up to you – what do you want to happen there.
  • Post-build actions now trigger Rundeck only on success.

If the rest is set well, time is for a test – ruin a build purposefully in a file, commit and push to refs/heads/:refs/for/ and sit and watch how Jenkins tells Gerrit to mark the commit that ruined the build as failed and to keep it in Limbo. Then do an amend with a fix, and Jenkins will re-build the stuff, tell Gerrit it is all ok now, and simultaneously send a signal to Rundeck. Gerrit will auto-merge this time good code to master, and the rest of the devs can pick up from there.

P.S. If people keep committing a new patchset instead of amending it for Gerrit, start yelling after the second time it happens, it might help do the manual monster merges that will follow…

Leave a Comment

Your email address will not be published. Required fields are marked *