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

Ignore merge changesets when filtering by module for polling

    Details

    • Similar Issues:

      Description

      If you configure a job with a module list, polling should not trigger a build
      just because an incoming merge changeset mentions a file contained in one of the
      modules. The list of files "modified" by a merge changeset in Mercurial is
      generally meaningless (which is why it is not displayed in the changelog page);
      someone merging changes made to an old parent rev with a new head will often
      produce a merge that claims to "modify" completely unrelated files which were in
      fact changed by other people in the other branch.

      (The "modified files" list for a merge changeset will always include files that
      were actually merged, but often includes other files that were simply picked up
      as-is from one or the other parent. The exact behavior seems to be a deep
      implementation detail of Mercurial with little significance to the SCM user.)

      Example: http://deadlock.netbeans.org/hudson/job/javacard/10/changes shows only
      http://hg.netbeans.org/main/rev/c487f4093cf5 which was a routine merge made by
      someone not working on javacard.* modules. The build therefore ran even though
      no changes were made to any files matching the javacard.* pattern.

      Even if the merge is nontrivial (i.e. required conflict resolution of some
      kind), and some of the resolved files were in the module list, it is very likely
      that it is one merge parent is a descendant of some regular changeset which
      modified those same files. Since the Hg plugin only deals with a single branch
      for a given job, either that regular changeset was already in a previous build,
      or it is coming it for the first time in this build - which would trigger a new
      build from the polling anyway.

      The only scenario I can think of where suppressing the file list for merge
      changesets would cause a build to not be triggered by polling when it really
      should be triggered (i.e. a pull & update will really cause some files in the
      module list to be changed relative to the previous build) is as follows: you
      modify file A in one changeset "a", modify B in another changeset "b", merge "a"
      and "b", modify another file "C" (even though there was no line-level conflict
      in it), commit the merge as changeset "c", finally push to a repo where some
      Hudson job is listening for changes in "C" only. This seems like a very unlikely
      scenario: most file edits in a merge are done only to resolve "hard" conflicts.
      Once in a blue moon you might modify some file closely related to one that was
      merged to avoid a semantic conflict (such as compilation error), but this is
      likely to be in the same module. Anyway most of the time you would only notice
      such conflicts to begin with, fixing them as a regular changeset, because a
      Hudson build failed - so polling based on merges would not be helpful.

        Attachments

          Issue Links

            Activity

            jglick Jesse Glick created issue -
            scm_issue_link SCM/JIRA link daemon made changes -
            Field Original Value New Value
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            jglick Jesse Glick made changes -
            Link This issue depends on JENKINS-7594 [ JENKINS-7594 ]
            abayer Andrew Bayer made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 135049 ] JNJira + In-Review [ 203226 ]

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                jglick Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: