-
Bug
-
Resolution: Unresolved
-
Major
-
Jenkins 2.37
workflow-multibranch-plugin 2.9.2 (also tested 2.10-beta1)
mercurial-plugin 1.57 (also tested 1.58-beta1)
RHEL 7.1 3.10.0-229.el7.x86_64
@ changeset: 2:785b6b539ffe
| tag: tip
| parent: 0:9dc4a8aaa2ce
| user: John Smith <example@example.com>
| date: Thu Jan 19 16:48:45 2017 +0000
| summary: This is a new head
|
| o changeset: 1:11545dbc8b9a
|/ user: John Smith <example@example.com>
| date: Thu Jan 19 16:48:25 2017 +0000
| summary: This is an old head
|
o changeset: 0:9dc4a8aaa2ce
user: John Smith <example@example.com>
date: Thu Jan 19 16:48:13 2017 +0000
summary: Initial commit
A workflow-multibranch-plugin job configured with a branch source of a Mercurial repository with the above changeset graph – in which there is a single branch with two heads – results in a job for that branch which builds changeset 1. However, changeset 2, not changeset 1, is the tip of the branch. By extension, this means that pushes on top of the branch-tip are never built (although they do trigger builds).
This behaviour is present with workflow-multibranch-plugin 2.9.2 and 2.10-beta1, and with mercurial-plugin 1.57 and 1.58-beta1. I have not tested historical versions.
I see that ResolveScmStep.ObserverImpl.observe() clobbers any previous revisions that it has considered when recording the revision to associate with the branch. This suggests two possible solutions:
I don't know which fits better with Jenkins' broader assumptions. The latter could be arranged such that the change only affects Mercurial. MercurialSCMSource.retrieve() parses the output of hg heads, which prints the tip of a branch before any other heads; I take this behaviour to be contractual and stable since the highest-ordinal-revision head is by definition the tip and hg heads does an explicit descending sort by ordinal revision.