I experienced a merge order problem whereby a gerrit change ("100" for arguments sake) was code reviewed after a later change ("101") had been code reviewed. This caused jenkins to build and release gerrit ID "100", and the code previously released from gerrit ID "101" was no longer the latest release.
I am wondering if I have a fundamental issue - my initial thoughts are that "choosing-strategy: gerrit" is correct for maven verify, but should be "choosing-strategy: default" when I build the code reviewed code from master.
I have the following jenkins config in JJB format for the job which build master and from which a release is generated:
parameters:
- string:
name: GERRIT_REFSPEC
default: refs/heads/master
triggers:
- gerrit:
trigger-on:
- change-merged-event
scm:
- git:
url: '{gerrit_url}/{repo}'
credentials-id: '{gerrit_credentials_id}'
name: origin
refspec: $GERRIT_REFSPEC
branches:
- $GERRIT_BRANCH
choosing-strategy: gerrit
UPDATE (April 2018): What seems to be happening is that following an event where a user has code reviewed and merged to master, the GERRIT_REFSPEC passed to Jenkins turns out to yield the patch, i.e. the code as it looked BEFORE it was merged into master.
Therefore, what I first thought was an obscure merge order problem, turns out that we were simply building the wrong thing in the first place. The choosing-strategy suggested, provides a decent enough work around, but I'm not sure I would call it a solution.