Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-41223

Multibranch pipelines with Mercurial: build selects oldest head

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • mercurial-plugin
    • 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.

          [JENKINS-41223] Multibranch pipelines with Mercurial: build selects oldest head

          Gregor Dick added a comment - - edited

          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:

          1. record the first revision seen only, or
          2. iterate (in SCMSource.fetch()) over the revisions in the opposite order.

          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.

          Gregor Dick added a comment - - edited 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: record the first revision seen only, or iterate (in SCMSource.fetch() ) over the revisions in the opposite order. 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.

          jglick can you take a look at this. From the description this looks to be the retrieve revision code starting with oldest first (which suggests it has always been an issue)

          Stephen Connolly added a comment - jglick can you take a look at this. From the description this looks to be the retrieve revision code starting with oldest first (which suggests it has always been an issue)

          Jesse Glick added a comment -

          Best to avoid multiple (unclosed) heads per named branch. Was never considered a supported use case.

          Jesse Glick added a comment - Best to avoid multiple (unclosed) heads per named branch. Was never considered a supported use case.

          Gregor Dick added a comment -

          Best to avoid multiple (unclosed) heads per named branch. Was never considered a supported use case.

          In view of this, is this bug a WONTFIX? That's fair enough if so, but it would be helpful if you could confirm this, please, so that I can go back to the drawing board if necessary.

          (In case it's of interest, the particular use case here is that Jenkins is running builds from a staging repository that shares some of its history with a development repository. Tags are only in the former, and are unclosed leaf changesets.)

          Gregor Dick added a comment - Best to avoid multiple (unclosed) heads per named branch. Was never considered a supported use case. In view of this, is this bug a WONTFIX? That's fair enough if so, but it would be helpful if you could confirm this, please, so that I can go back to the drawing board if necessary. (In case it's of interest, the particular use case here is that Jenkins is running builds from a staging repository that shares some of its history with a development repository. Tags are only in the former, and are unclosed leaf changesets.)

          Jesse Glick added a comment -

          Probably the right response to this weird case would be to create branch projects like default, default@2, etc. Or simply refuse to create any heads from this repository, and print an explanation to the indexing log. Quietly misbehaving is a bug. In any event I have no real expectation of working on this in the foreseeable future—this plugin is in minimal maintenance mode only.

          Jesse Glick added a comment - Probably the right response to this weird case would be to create branch projects like default , default@2 , etc. Or simply refuse to create any heads from this repository, and print an explanation to the indexing log. Quietly misbehaving is a bug. In any event I have no real expectation of working on this in the foreseeable future—this plugin is in minimal maintenance mode only.

            Unassigned Unassigned
            gd_sfc Gregor Dick
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: