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

Multibranch pipelines with Mercurial: build selects oldest head

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: mercurial-plugin
    • Labels:
    • Environment:
      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
    • Similar Issues:

      Description

      @  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.

        Attachments

          Activity

          Hide
          gd_sfc 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.

          Show
          gd_sfc 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.
          Hide
          stephenconnolly Stephen Connolly added a comment -

          Jesse Glick 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)

          Show
          stephenconnolly Stephen Connolly added a comment - Jesse Glick 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)
          Hide
          jglick Jesse Glick added a comment -

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

          Show
          jglick Jesse Glick added a comment - Best to avoid multiple (unclosed) heads per named branch. Was never considered a supported use case.
          Hide
          gd_sfc 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.)

          Show
          gd_sfc 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.)
          Hide
          jglick 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.

          Show
          jglick 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.

            People

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

              Dates

              Created:
              Updated: