0

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.

Jepper
  • 1,092
  • 3
  • 11
  • 24
  • I didn't understand you point... the "100" release (the latest build) includes both "100" and "101" patches, right? I'm confused with your word "patch"... in Gerrit terms, when you say "patch" do you want to say "change" or "patchset"? – Marcelo Ávila de Oliveira Apr 29 '16 at 11:57
  • I had to look up the difference - it's "change". Thanks for pointing out, I have updated the question to reflect. – Jepper Apr 29 '16 at 21:13
  • Ok. I think everything is correct with your configuration. When change 101 is submitted, the job is trigged and the build (with change 101) is done. After, when change 100 is submitted, the job is trigged again and the build (with changes 100 and 101) is done. Acctually, I didn't understand what is your issue... – Marcelo Ávila de Oliveira Apr 30 '16 at 14:41
  • If I look at the directory structure in Jenkins workspace following 100, I can see that other changes that were made in 101 are not there. Hence it seems, one ought to rebase on top of master on a local branch and then build for a correct verify. – Jepper Apr 30 '16 at 15:16
  • You could try to remove the "$GERRIT_REFSPEC" from scm > refspec field (scm > name = "origin" is not needed too). – Marcelo Ávila de Oliveira Apr 30 '16 at 23:31

0 Answers0