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

Git path polling ignores do not work in Pipeline jobs

      Multibranch pipeline jobs seem to ignore git path polling rules when attempting to detect indexing changes and schedule builds.

      More specifically:

      • I am using a "Periodically if not otherwise run" build trigger
      • I tested "Git polling ignores commits in certain paths" with the following:

      1) Only including paths that I care about:
      Included:
      that-path-I-care-about/.*
      Excluded:
      (empty)

      2) Including paths I care about and excluding a specific path:
      Included:
      that-path-I-care-about/.*
      Excluded:
      that-path-I-want-to-ignore/.*

      3) Just using excluded paths:
      Included:
      (empty)
      Excluded:
      that-path-I-want-to-ignore/.*

      None of them work as expected. Builds are triggered anytime a change is committed to the repo.

          [JENKINS-36836] Git path polling ignores do not work in Pipeline jobs

          S D added a comment -

          +1, polling rules do not work for simple pipeline & multi-branch pipeline jobs. In my case I'm trying to ignores commits from certain users.

          S D added a comment - +1, polling rules do not work for simple pipeline & multi-branch pipeline jobs. In my case I'm trying to ignores commits from certain users.

          Same issue here. Ignoring commits messages does not work with multibranch pipeline.

          Slawomir Demichowicz added a comment - Same issue here. Ignoring commits messages does not work with multibranch pipeline.

          Gleb Samsonov added a comment -

          for me, it looks like all include/exclude rules don't work properly if we'll use jobs without the persistent workspace (any pipeline-jobs for example). It caused by a git-plugin code (https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java). This plugin tries to find a workspace for polling and if this workspace doesn't exist - it compares revision hashes from the latest build and from actual repo (`git ls-remote -h`) . And obviously if we've updated repo these hashes differ so new build is starting

          Gleb Samsonov added a comment - for me, it looks like all include/exclude rules don't work properly if we'll use jobs without the persistent workspace (any pipeline-jobs for example). It caused by a git-plugin code ( https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java ). This plugin tries to find a workspace for polling and if this workspace doesn't exist - it compares revision hashes from the latest build and from actual repo (`git ls-remote -h`) . And obviously if we've updated repo these hashes differ so new build is starting

          Can this functionality be moved to later stages?
          So the repository is still fetched, but some steps can be skipped in case there are no appropriate changes as described in JENKINS-37978.

          Alexander Vorobiev added a comment - Can this functionality be moved to later stages? So the repository is still fetched, but some steps can be skipped in case there are no appropriate changes as described in JENKINS-37978 .

          Path inclusions and exclusions (in a NON-MULTIBRANCH project) seem to work fine when there is a persistent workspace (we use the master to Checkout all code - then move on to a worker node). This is the case in NON-PIPELINE jobs as well and has been as such for some time. The USER inclusion/exclusion do not work in pipelines. Definitely Hoping for a fix to the user exclusions soon as our automated tagging and version bumping always results in a new build.

          Michael Andrews added a comment - Path inclusions and exclusions (in a NON-MULTIBRANCH project) seem to work fine when there is a persistent workspace (we use the master to Checkout all code - then move on to a worker node). This is the case in NON-PIPELINE jobs as well and has been as such for some time. The USER inclusion/exclusion do not work in pipelines. Definitely Hoping for a fix to the user exclusions soon as our automated tagging and version bumping always results in a new build.

          Jesse Glick added a comment -

          It is well known that you cannot use path exclusions when Git is configured to perform master-based polling, due to limitations in the Git network protocol. Would be solvable only by using a master repo cache the way the Mercurial plugin does, and in fact git already does for multibranch projects. I think this is already filed somewhere.

          Polling exclusions are not currently supported for multibranch projects under any circumstances. That is probably also already filed somewhere.

          Jesse Glick added a comment - It is well known that you cannot use path exclusions when Git is configured to perform master-based polling, due to limitations in the Git network protocol. Would be solvable only by using a master repo cache the way the Mercurial plugin does, and in fact git already does for multibranch projects. I think this is already filed somewhere. Polling exclusions are not currently supported for multibranch projects under any circumstances. That is probably also already filed somewhere.

          User exclusions are now working. This is from one of our pipelines:

          Ignored commit 73adf973ee91ff5b21c0638878eee33df7204544: Found excluded author: Jenkins
          

          Michael Andrews added a comment - User exclusions are now working. This is from one of our pipelines: Ignored commit 73adf973ee91ff5b21c0638878eee33df7204544: Found excluded author: Jenkins

          Ron Swanson added a comment -

          killdash9 Good day. Can you please say more about how you got that working?

          Ron Swanson added a comment - killdash9 Good day. Can you please say more about how you got that working?

          killdash9 I can get those log messages, however in situations where there is no actual workspace on a build node it still triggers the build (even though there's a duplicate workspace on the Jenkins master server). So I believe it works but still doesn't recognize using the master servers local copy as the source to make the determination. Which is not ideal.

          Maxfield Stewart added a comment - killdash9 I can get those log messages, however in situations where there is no actual workspace on a build node it still triggers the build (even though there's a duplicate workspace on the Jenkins master server). So I believe it works but still doesn't recognize using the master servers local copy as the source to make the determination. Which is not ideal.

          Venkatesh added a comment -

          Can anyone please confirm if this is working for Multibranch Pipeline jobs? Also, please provide some syntax. It's a humble request.

          Venkatesh added a comment - Can anyone please confirm if this is working for Multibranch Pipeline jobs? Also, please provide some syntax. It's a humble request.

            Unassigned Unassigned
            prestonj Preston Jennings
            Votes:
            21 Vote for this issue
            Watchers:
            35 Start watching this issue

              Created:
              Updated:
              Resolved: