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

Mercurial poll triggers build due to unrelated changes

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • mercurial-plugin
    • None

      The current Mercurial poll command is formulated such that it may falsely detect new changes if there have ever been any branches with the same name as that relevant to the build, but which are not ancestors of the current working-directory revision in terms of the revision DAG.

      If the repository happens to contain another branch with the same name, Jenkins will continuously build the project and the only way to stop it is to push a dummy merge of that other branch into the line of development Jenkins is supposed to build.

      A better way to ask for new descendants of the current working-directory revision would be this:

      hg log --branch $branch --rev "descendants(children($revision))"

      The children predicate is needed because descendants always include the named revision itself.

          [JENKINS-13842] Mercurial poll triggers build due to unrelated changes

          Jesse Glick added a comment -

          A self-contained reproducible test case is worth a thousand words.

          Using revsets is probably not feasible since they will not work on older versions of Mercurial. It would be possible to check the Hg version and switch behavior, but this makes testing ineffective.

          Jesse Glick added a comment - A self-contained reproducible test case is worth a thousand words. Using revsets is probably not feasible since they will not work on older versions of Mercurial. It would be possible to check the Hg version and switch behavior, but this makes testing ineffective.

          Thomas Lotze added a comment -

          What would a test case for this look like? A repository with a description of which revisions to push to another repository visible to a Jenkins instance at what point? Some Jenkins configuration? I'm not sure that would end up more concise than the short description I gave already, but I can try when I know what you'd like to see.

          OTOH, I don't understand that comment about the mercurial version. Which versions of mercurial are you committed to support? Revsets have been part of mercurial since version 1.5 or 1.6 - do you need to support versions as old as that by new Jenkins releases?

          Thomas Lotze added a comment - What would a test case for this look like? A repository with a description of which revisions to push to another repository visible to a Jenkins instance at what point? Some Jenkins configuration? I'm not sure that would end up more concise than the short description I gave already, but I can try when I know what you'd like to see. OTOH, I don't understand that comment about the mercurial version. Which versions of mercurial are you committed to support? Revsets have been part of mercurial since version 1.5 or 1.6 - do you need to support versions as old as that by new Jenkins releases?

          Jesse Glick added a comment -

          A test case would be something like a bundle repo (or a set of Hg commands to create an equivalent repo starting with hg init), plus the SCM snippet from a job config.xml - whatever concrete instructions are needed to reproduce the issue from scratch. (A unit test is of course ideal but more work to prepare if you have not played with the sources.)

          Regarding Mercurial versions, my own organization runs 1.3.1 on some servers due to a serious regression in the merge algorithm in 1.4. General policy for the plugin is that it should work on 1.0+ unless there is a compelling need to require a newer version; certain optional features are conditionally enabled based on version, such as hg relink.

          Jesse Glick added a comment - A test case would be something like a bundle repo (or a set of Hg commands to create an equivalent repo starting with hg init), plus the SCM snippet from a job config.xml - whatever concrete instructions are needed to reproduce the issue from scratch. (A unit test is of course ideal but more work to prepare if you have not played with the sources.) Regarding Mercurial versions, my own organization runs 1.3.1 on some servers due to a serious regression in the merge algorithm in 1.4. General policy for the plugin is that it should work on 1.0+ unless there is a compelling need to require a newer version; certain optional features are conditionally enabled based on version, such as hg relink.

          Thomas Lotze added a comment -

          Just out of curiosity: half a year has passed, so has anything changed regarding the minimum supported mercurial version?

          Thomas Lotze added a comment - Just out of curiosity: half a year has passed, so has anything changed regarding the minimum supported mercurial version?

          Thomas Lotze added a comment -

          The same question after another year has gone by: is supporting Mercurial as old as 1.4 still a goal, blocking use of better change detection?

          Thomas Lotze added a comment - The same question after another year has gone by: is supporting Mercurial as old as 1.4 still a goal, blocking use of better change detection?

          Jesse Glick added a comment -

          At this point requiring 1.4+ is probably reasonable. Still unclear to me that revsets are the appropriate fix for this issue, since there is no test case; historical branch names should not really matter since what the plugin cares about is whether the last built revision is distinct from the current expansion of the target revision, which ought to be using the current definition of the branch. (Check behavior against 1.50-beta-1 which added tag support.)

          Jesse Glick added a comment - At this point requiring 1.4+ is probably reasonable. Still unclear to me that revsets are the appropriate fix for this issue, since there is no test case; historical branch names should not really matter since what the plugin cares about is whether the last built revision is distinct from the current expansion of the target revision, which ought to be using the current definition of the branch. (Check behavior against 1.50-beta-1 which added tag support.)

            jglick Jesse Glick
            tlotze Thomas Lotze
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: