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

Pipeline polling ignores special polling rules

      The git plugin currently offers several special rules on polling:

      1. Polling ignores commits from certain users
      2. Polling ignores commits from certain paths (Included/Excluded regions)
      3. Polling ignores commits with certain messages
      4. Branch specifier

      For example:
      checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'UserExclusion', excludedUsers: 'dvader'], [$class: 'PathRestriction', excludedRegions: 'One/.*', includedRegions: 'Test/.*'], [$class: 'MessageExclusion', excludedMessage: '.\\[maven-release-plugin
      ].
      ']], gitTool: 'Default', submoduleCfg: [], userRemoteConfigs: [[credentialsId: '...', url: 'ssh://git@bitbucket.org/test.git']]])

      If a commit is committed to bitbucket.org/test.git, regardless of the user, location, branch or message, the step that includes the checkout will be run.

      Similar issue has been reported in:

          [JENKINS-36195] Pipeline polling ignores special polling rules

          Can we also make it possible to pass properties (like excludedUsers) from git step to checkout step, as currently git step allows only for url, branch and credentialsId. It would make life a lot easier, as we wouldn't have to switch from git to checkout (which is less readable) just to pass some property.

          Krzysztof Wolny added a comment - Can we also make it possible to pass properties (like excludedUsers ) from git step to checkout step, as currently git step allows only for url , branch and credentialsId . It would make life a lot easier, as we wouldn't have to switch from git to checkout (which is less readable) just to pass some property.

          Desperately need this feature working

          Hafizullah Nikben added a comment - Desperately need this feature working

          Jesse Glick added a comment -

          vanta the git step is only for the most simplistic use cases. Use checkout.

          Jesse Glick added a comment - vanta the git step is only for the most simplistic use cases. Use checkout .

          Jesse Glick added a comment -

          To be clear, from the description I am assuming this is a bug not a feature. Would require someone to take time to do the analysis. Offhand I have no idea where the problem lies.

          Jesse Glick added a comment - To be clear, from the description I am assuming this is a bug not a feature. Would require someone to take time to do the analysis. Offhand I have no idea where the problem lies.

          Krzysztof Wolny added a comment - - edited

          jglick I know that, and I think it should be easy to pass properties to "parent". But that's the point of using git - simplicity. If you go this way you proposed further, we can remove git - and use checkout, right?

          Krzysztof Wolny added a comment - - edited jglick I know that, and I think it should be easy to pass properties to "parent". But that's the point of using git - simplicity. If you go this way you proposed further, we can remove git - and use checkout , right?

          Wim Ederveen added a comment -

          I have an even trickier problem. We use standardized jenkinsfiles from a seperate repository to facilitate 200+ java projects. And these Jenkinsfiles are fed with parameters in the job, with properties like gitUrl and branchName. These values are used in the jenkinsfiles in a checkout step. So the 'pipeline script from SCM' bit in the job is not the git repository that contains the code. It does pick up commit changes in the parameterized git repository, but exclusions are not honored.
          So we have git repository 'A' containing jenkinsfiles. These are used in the pipelinescript from SCM bit in the Job.
          And we have git repository 'B' containing sourcecode to be built. The git url of this repository is fed to the jenkinsfile from repository 'A'
          The problem now is that we have an SCM trigger on the pipeline job to run every night, but the [maven-release-plugin] triggers itself because of version update commits. So we want to exclude either the jenkins user commits or commits containing [maven-release-plugin].
          I've tried adding exclusions to the pipeline script from SCM additional behaviours as well as in the jenkinsfiles checkout step.
          We really need this for our pipeline implementation

          Wim Ederveen added a comment - I have an even trickier problem. We use standardized jenkinsfiles from a seperate repository to facilitate 200+ java projects. And these Jenkinsfiles are fed with parameters in the job, with properties like gitUrl and branchName. These values are used in the jenkinsfiles in a checkout step. So the 'pipeline script from SCM' bit in the job is not the git repository that contains the code. It does pick up commit changes in the parameterized git repository, but exclusions are not honored. So we have git repository 'A' containing jenkinsfiles. These are used in the pipelinescript from SCM bit in the Job. And we have git repository 'B' containing sourcecode to be built. The git url of this repository is fed to the jenkinsfile from repository 'A' The problem now is that we have an SCM trigger on the pipeline job to run every night, but the [maven-release-plugin] triggers itself because of version update commits. So we want to exclude either the jenkins user commits or commits containing [maven-release-plugin] . I've tried adding exclusions to the pipeline script from SCM additional behaviours as well as in the jenkinsfiles checkout step. We really need this for our pipeline implementation

          Wim Ederveen added a comment -

          Just wanted to share our workaround for the polling issue.
          We came up with a solution using the groovy script. It is not perfect but it helps us by preventing unwanted releases triggered by the maven-release-plugin.
          In one of the first stages we check the "git log" for the comments of the last day using:
          def gitComments = sh(returnStdout: true, script: "git log --pretty=format:\"%cd  %h  %s\" --date=short --since=\"last day\"")
          We then parse this list to see if it only contains [maven-release-plugin] commits. If so we stop the Jenkins job using the following lines:
          currentBuild.result = "NOT_BUILT"
          error "Pipeline not built. No new user commits found"

          It is a bit ugly but the job status shows up as NOT_BUILT and that is enough for us.
           

          Wim Ederveen added a comment - Just wanted to share our workaround for the polling issue. We came up with a solution using the groovy script. It is not perfect but it helps us by preventing unwanted releases triggered by the maven-release-plugin. In one of the first stages we check the "git log" for the comments of the last day using: def gitComments = sh(returnStdout: true, script: "git log --pretty=format:\"%cd  %h  %s\" --date=short --since=\"last day\"") We then parse this list to see if it only contains [maven-release-plugin]  commits. If so we stop the Jenkins job using the following lines: currentBuild.result = "NOT_BUILT" error "Pipeline not built. No new user commits found" It is a bit ugly but the job status shows up as NOT_BUILT and that is enough for us.  

          Mor L added a comment - - edited

          It's a bummer to have something given to you by the Pipeline Syntax page, only to figure out it is not working properly after some trial and error.

          If it's not working properly - Pipeline Syntax page should not allow to configure it, and if someone tries to - it should at least generate a warning during runtime (as long as it is a known limitation and not an undiscovered bug).

          Mor L added a comment - - edited It's a bummer to have something given to you by the Pipeline Syntax page, only to figure out it is not working properly after some trial and error. If it's not working properly - Pipeline Syntax page should not allow to configure it, and if someone tries to - it should at least generate a warning during runtime (as long as it is a known limitation and not an undiscovered bug).

          Mark Waite added a comment -

          pyrocks I believe a set of changes currently being prepared (or at least discussed) may remove the "ill-advised" additional behaviours from the pipeline syntax (like the "Checkout to subdirectory" and "Ignore polling ..." and others)

          Mark Waite added a comment - pyrocks I believe a set of changes currently being prepared (or at least discussed) may remove the "ill-advised" additional behaviours from the pipeline syntax (like the "Checkout to subdirectory" and "Ignore polling ..." and others)

          Mor L added a comment -

          markewaite When that happens, the question that remains is whether this issue would be considered a bug or RFE... I prefer to see it as a bug.

          We work around this by checking the commit authors post checkout and abort the build if only the build user committed. Soon we will switch to post-receive hook and have no need for this but its still worth doing.

          Mor L added a comment - markewaite When that happens, the question that remains is whether this issue would be considered a bug or RFE... I prefer to see it as a bug. We work around this by checking the commit authors post checkout and abort the build if only the build user committed. Soon we will switch to post-receive hook and have no need for this but its still worth doing.

          Mark Waite added a comment -

          I consider this a request for enhancement, rather than a bug. The git plugin special polling rules have been consciously chosen to not apply in the pipeline case. They are not a general purpose technique across all the SCM systems supported in pipeline.

          Mark Waite added a comment - I consider this a request for enhancement, rather than a bug. The git plugin special polling rules have been consciously chosen to not apply in the pipeline case. They are not a general purpose technique across all the SCM systems supported in pipeline.

          markewaite : I understand the decision made, but it's not obvious from UI. UI clearly shows those options, and it's confusing why they are not working. 

          Slawomir Demichowicz added a comment - markewaite : I understand the decision made, but it's not obvious from UI. UI clearly shows those options, and it's confusing why they are not working. 

          Mark Waite added a comment -

          demee the UI confusion is resolved or will be resolved with the release of git plugin 3.4.0 and the SCMNavigator improvements from stephenconnolly. I believe this still should remain open as an enhancement request for those users who want pipeline to be able to ignore certain users or certain regions.

          Mark Waite added a comment - demee the UI confusion is resolved or will be resolved with the release of git plugin 3.4.0 and the SCMNavigator improvements from stephenconnolly . I believe this still should remain open as an enhancement request for those users who want pipeline to be able to ignore certain users or certain regions.

          I think this would be best implemented as a Filtering trait if people want to ignore branches from certain users.

          If people want the branches to remain but ignore specific commits, the best bet IMHO is to have the pipeline abort in a defined way from the Jenkinsfile parse so that Jenkins is happy that the commit has been built and everyone else is happy that the build did nothing

          Stephen Connolly added a comment - I think this would be best implemented as a Filtering trait if people want to ignore branches from certain users. If people want the branches to remain but ignore specific commits, the best bet IMHO is to have the pipeline abort in a defined way from the Jenkinsfile parse so that Jenkins is happy that the commit has been built and everyone else is happy that the build did nothing

          Not sure if this is the place to post this, but it may be useful to someone.

          I have it implement this way (outside of `step` block) 

           

           

          if (stash.isJenkinsLastAuthor() && !params.SKIP_CHANGELOG_CHECK) {
              echo "No more new changes, stopping pipeline"
              currentBuild.result = "SUCCESS"
              return
          }
          
          

           

          setting SKIP_CHANGELOG_CHECK - this allows me to force build ( in case I do want the pipeline to run regardless of who was the last one to commit )

          Then it looks like this in the UI

          Slawomir Demichowicz added a comment - Not sure if this is the place to post this, but it may be useful to someone. I have it implement this way (outside of `step` block)      if (stash.isJenkinsLastAuthor() && !params.SKIP_CHANGELOG_CHECK) { echo "No more new changes, stopping pipeline" currentBuild.result = "SUCCESS" return }   setting SKIP_CHANGELOG_CHECK - this allows me to force build ( in case I do want the pipeline to run regardless of who was the last one to commit ) Then it looks like this in the UI

          Jesse Glick added a comment -

          As I have noted several times here, there are two completely related cases.

          For a standalone Pipeline job, all SCM features including exclusions are supposed to work exactly as they do for freestyle projects. If they do not, that is a bug. I just do not know how to reproduce it.

          For a branch project, there is no support for commit exclusions, nor should any such be offered in the recently amended UX. If we want to add support, I think it should just work as people expect: branch changes with only insignificant changes should not trigger new builds.

          In either case, you always have the workaround of inspecting currentBuild.changeSets from a script and returning early if the changes look boring. JENKINS-27092 would allow you to do this with the error step so you could get the natural NOT_BUILT status (and not have to deal with a return statement, which does not work inside a library, closure, etc.).

          Jesse Glick added a comment - As I have noted several times here, there are two completely related cases. For a standalone Pipeline job, all SCM features including exclusions are supposed to work exactly as they do for freestyle projects. If they do not, that is a bug. I just do not know how to reproduce it. For a branch project, there is no support for commit exclusions, nor should any such be offered in the recently amended UX. If we want to add support, I think it should just work as people expect: branch changes with only insignificant changes should not trigger new builds. In either case, you always have the workaround of inspecting currentBuild.changeSets from a script and returning early if the changes look boring.  JENKINS-27092 would allow you to do this with the error step so you could get the natural NOT_BUILT status (and not have to deal with a return statement, which does not work inside a library, closure, etc.).

          Stephan Watermeyer added a comment - - edited

          +1 to have the "Polling ignores commits from certain users" option available for Multibranch Pipeline Plugins. I would like to ignore the commits from the Jenkins-User. 

          The Reason for that: We are doing java development and using Maven with the official maven-release-plugin. Thus the call of "mvn release:prepare release:perform" results in a commit on the current branch. And this commit results then in a new build.

          I can check for the workaround mentioned by Jesse, but at least i want to have at less scripting as possible in our Jenkinsfiles. So having the option in the Jenkins GIT-Plugin would be much helpful.

          //edit: The Option "Polling ignores commits from certain users" is available in the old plugin version 3.3.2 

          Stephan Watermeyer added a comment - - edited +1 to have the "Polling ignores commits from certain users" option available for Multibranch Pipeline Plugins. I would like to ignore the commits from the Jenkins-User.  The Reason for that: We are doing java development and using Maven with the official maven-release-plugin. Thus the call of "mvn release:prepare release:perform" results in a commit on the current branch. And this commit results then in a new build. I can check for the workaround mentioned by Jesse, but at least i want to have at less scripting as possible in our Jenkinsfiles. So having the option in the Jenkins GIT-Plugin would be much helpful. //edit: The Option "Polling ignores commits from certain users" is available in the old plugin version 3.3.2 

          Jesse Glick added a comment -

          phreakadelle please reread my above comments. You cannot use commit exclusions in multibranch Pipeline jobs. They are available in standalone jobs. This is by design. If you want a job doing Maven releases, it should be a standalone job, not a branch job.

          Jesse Glick added a comment - phreakadelle please reread my above comments. You cannot use commit exclusions in multibranch Pipeline jobs . They are available in standalone jobs. This is by design. If you want a job doing Maven releases, it should be a standalone job, not a branch job.

          Stephan Watermeyer added a comment - - edited

          Thanks jglick for your reply. Understood. 

          So we have to create two jobs per component, one job to make the ci-builds for each branch and another job to release the component. So i've to create/maintain a second Jenkinsfile in each component. Would this be the recommended way to go? That would be nearly the way how jenkins-plugins are developed but i am still unsure if Jenkins should be used in that way.

          Further: I am still thinking about an option to extend my Jenkinsfile to update the "scm-revision-hash.xml" file after a mvn release. My idea is to put in something in my pipeline like:

          ...
          stage('Release') {
            when {
              branch 'master'
            }
          
            steps {
              sh 'mvn release:prepare release:perform'
          
              // get the latest commit id
              sh '$LASTCOMMITID=git log -1 --pretty=format:"%H";'
          
              // Search and Replace the Hash in the scm-revision-hash.xml file with $LASTCOMMITID
              sh 'search/replace in jobs/<projectname>/<branchname>/scm-revision-hash.xml and replace hash with $LASTCOMMITID'
            }
          }
          ...

          What do you think? What would be a nice & clean way to update the scm-revision-hash.xml file? Or is this just crap?

          Stephan Watermeyer added a comment - - edited Thanks jglick for your reply. Understood.  So we have to create two jobs per component, one job to make the ci-builds for each branch and another job to release the component. So i've to create/maintain a second Jenkinsfile in each component. Would this be the recommended way to go ? That would be nearly the way how jenkins-plugins are developed but i am still unsure if Jenkins should be used in that way. Further: I am still thinking about an option to extend my Jenkinsfile to update the "scm-revision-hash.xml" file after a mvn release. My idea is to put in something in my pipeline like: ... stage( 'Release' ) { when { branch 'master' } steps { sh 'mvn release:prepare release:perform' // get the latest commit id sh '$LASTCOMMITID=git log -1 --pretty=format: "%H" ;' // Search and Replace the Hash in the scm-revision-hash.xml file with $LASTCOMMITID sh 'search/replace in jobs/<projectname>/<branchname>/scm-revision-hash.xml and replace hash with $LASTCOMMITID' } } ... What do you think? What would be a nice & clean way to update the scm-revision-hash.xml file? Or is this just crap?

          Jesse Glick added a comment -

          phreakadelle yes you should have a separate job definition for release builds, based on some Pipeline script from SCM, but not multibranch.

          I do not advise trying to touch scm-revision-hash.xml. This is not supported, and is also incompatible with a secured Jenkins instance.

          Jesse Glick added a comment - phreakadelle yes you should have a separate job definition for release builds, based on some Pipeline script from SCM, but not multibranch. I do not advise trying to touch scm-revision-hash.xml . This is not supported, and is also incompatible with a secured Jenkins instance.

          ron swanson added a comment -

          Good day.

          I have been watching this item for a while and thought I would chime in.

          We have a non-multi branch pipeline project that does the maven release steps and during the release process it will check the pom back in with updates to <version> and we encountered this issue where the polling exclusion doesn't work to ignore changes made by the build user, so we would get stuck in an infinite build loop until we killed the job.

          The work around I came up with was to use the 'ci-skip' feature of the GitLab CI project trigger and I modified our maven check-in comments to prepend '[ci-skip]' to any of the check-in commit messages performed by our maven release process.

          jglick   Let me dig up my test jobs and version info to be able to pass on some information about reproducing this.   I had encountered this a while ago and haven't tested it with recent versions,  so it will be good to make sure I have the details of the problem again.

          Thanks for all your work.

          Ron

          ron swanson added a comment - Good day. I have been watching this item for a while and thought I would chime in. We have a non-multi branch pipeline project that does the maven release steps and during the release process it will check the pom back in with updates to <version> and we encountered this issue where the polling exclusion doesn't work to ignore changes made by the build user, so we would get stuck in an infinite build loop until we killed the job. The work around I came up with was to use the 'ci-skip' feature of the GitLab CI project trigger and I modified our maven check-in comments to prepend ' [ci-skip] ' to any of the check-in commit messages performed by our maven release process. jglick    Let me dig up my test jobs and version info to be able to pass on some information about reproducing this.   I had encountered this a while ago and haven't tested it with recent versions,  so it will be good to make sure I have the details of the problem again. Thanks for all your work. Ron

          Jesse Glick added a comment -

          rswanso it is expected that a Maven release will trigger a new CI build by default, since sources have indeed changed (even if only trivially). There should be no “loop” since a job with an SCM trigger should never be performing releases! A release job should have only a manual trigger.

          Please keep it to the user’s list. This issue is about a claimed bug which I do not know how to reproduce: that in a standalone, not multibranch, job using an SCM trigger and an SCM checkout which specifies polling exclusions using whatever SCM-specific configuration (reported here for Git), that ignorable commits nonetheless trigger builds. No other comments are relevant in this issue.

          Jesse Glick added a comment - rswanso it is expected that a Maven release will trigger a new CI build by default, since sources have indeed changed (even if only trivially). There should be no “loop” since a job with an SCM trigger should never be performing releases! A release job should have only a manual trigger. Please keep it to the user’s list. This issue is about a claimed bug which I do not know how to reproduce: that in a standalone, not multibranch , job using an SCM trigger and an SCM checkout which specifies polling exclusions using whatever SCM-specific configuration (reported here for Git), that ignorable commits nonetheless trigger builds. No other comments are relevant in this issue.

          ron swanson added a comment -

          jglick    Sorry, i thought I was talking about what was relevant.  I have a non-multi branch project which attempts to use  excludedUsers to ignore checkins that were made by the user running the build.

          I DONT want to get into a discussion about what maven should or shouldn't be doing, but I think I am trying to stay on what I think the topic is, which to me is, the excludedUsers doesn't work in the scm checkout to ignore checkouts by specific users.

          Am I still off-base?

          Thanks

          Ron

          ron swanson added a comment - jglick     Sorry, i thought I was talking about what was relevant.  I have a non-multi branch project which attempts to use  excludedUsers to ignore checkins that were made by the user running the build. I DONT want to get into a discussion about what maven should or shouldn't be doing, but I think I am trying to stay on what I think the topic is, which to me is, the excludedUsers doesn't work in the scm checkout to ignore checkouts by specific users. Am I still off-base? Thanks Ron

          Jesse Glick added a comment -

          the excludedUsers doesn't work in the scm checkout to ignore checkouts by specific users

          If reproducible (using a minimal self-contained test case etc.), that is a bug.

          Jesse Glick added a comment - the excludedUsers doesn't work in the scm checkout to ignore checkouts by specific users If reproducible (using a minimal self-contained test case etc.), that is a bug.

          ron swanson added a comment -

          jglick   Thanks....  and I have to ask as I am new to this, do you mean a test case like this?

          https://github.com/jenkinsci/git-plugin/blob/4e38437ca3aed7b976b687a2e006e1987276437d/src/test/java/hudson/plugins/git/GitSCMTest.java#L483

           

          Thanks

          Ron

          ron swanson added a comment - jglick    Thanks....  and I have to ask as I am new to this, do you mean a test case like this? https://github.com/jenkinsci/git-plugin/blob/4e38437ca3aed7b976b687a2e006e1987276437d/src/test/java/hudson/plugins/git/GitSCMTest.java#L483   Thanks Ron

          Jesse Glick added a comment -

          Well an actual JUnit test case reproducing the bug (for bonus points, in a PR with an initial @Ignore annotation) is great, since then a developer can get straight to work analyzing and fixing it. But detailed manual steps suffice: install Jenkins 2.xx, install such-and-such plugins, create a job with the following script, run the following Git commands in a shell, whatever.

          AFAICT neither this nor this currently test polling exclusions explicitly. This call is where Pipeline passes control to the SCM to determine whether there are changes, implemented for example here.

          Jesse Glick added a comment - Well an actual JUnit test case reproducing the bug (for bonus points, in a PR with an initial @Ignore annotation) is great, since then a developer can get straight to work analyzing and fixing it. But detailed manual steps suffice: install Jenkins 2.xx, install such-and-such plugins, create a job with the following script, run the following Git commands in a shell, whatever. AFAICT neither this  nor this  currently test polling exclusions explicitly. This call  is where Pipeline passes control to the SCM to determine whether there are changes, implemented for example here .

          ron swanson added a comment -

          Thanks for that detailed response, that gives me some good stuff to look at.

          I have an environment that i just tested this out in, but i will have to recreate to make sure I get the details right and I can post it back.  Doing a PR is a bit out of my wheelhouse, but I do want to learn how to write Jenkins plugins, so this is good.

          Thanks

          Ron

          ron swanson added a comment - Thanks for that detailed response, that gives me some good stuff to look at. I have an environment that i just tested this out in, but i will have to recreate to make sure I get the details right and I can post it back.  Doing a PR is a bit out of my wheelhouse, but I do want to learn how to write Jenkins plugins, so this is good. Thanks Ron

          Same problem here, using:

          I have tried to ignore poll SCM with Excluded Users and Excluded Messages, none worked.

           

          Ignacio Ocampo added a comment - Same problem here, using: Jenkins ver. 2.60.3 https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin  v 2.5 I have tried to ignore poll SCM with Excluded Users  and Excluded Messages , none worked.  

          ron swanson added a comment -

          I am at

          Jenkins ver  2.46.2

          https://plugins.jenkins.io/gitlab-plugin  1.4.7

          https://plugins.jenkins.io/workflow-scm-step 2.5

           

           My test case was:

          -Pipeline job that checked out single Jenkinsfile

          -"Poll SCM" was checked, but schedule was empty

          -"Triggered builds remotely (eg from scripts)"  and I set a Authentication token

          -Gitlab has this trigger for my job: http://myserver:8080/job/test.infinite.loop/build?token=mytoken

          -Tried the exclude logic from the job config in UI, as well as from in Jenkinsfile using "checkout scm".

          -My Jenkinsfile calls these maven commands to simulate a release: versions:set, versions:commit, scm:add and scm:checkin, which just updates the pom.xml file with the next version.

           

           

          I tested every combination I could think of.

          Setting different user.name at checkout time using additional behaviour, changing displayname as defined in /etc/passwd, adding multiple users to exclude list, trying logic at job level, and in pipeline using 'checkout SCM'.

          Something to note is Jenkins reports the job was triggered by the user  'jenkins' as that is the user Jenkins is running as, but the user that checks into GIT is what is defined as the display name from /etc/passwd file.  So I am not exactly sure what user it SHOULD be expecting to try to exclude, but I have tried to exclude all the different users, individually as well as in a multiple list.

           

          This is from  the "Changes" link in a particular build and shows that 'jenkins' did it, as 'jenkins' is the unix user that Jenkins is running under.

          *Commit f3b85jh3jh4k3j4h5kj3h45kj2k3j2bfc9c99727c566ba718c2 by *jenkins   [ci-skip] updating pom to 2017.08.427

           

          But in GITLAB, the checkin comment shows the user that is defined as the display name in the /etc/passwd file for the user.  I have also tried changing that displayname to match the actual username, so it is the same value on both sides, to no avail.

             [ci-skip] updating pom to 2017.08.427
             CMJenkins committed 2 minutes ago

           
          In my pom i use these GIT connection urls, so I have an SSH key setup between the user jenkins is running as, and the user we are connecting to GIT with, which is a different user, (and I've  tried to exclude that one too)
           
          <connection>scm:git:ssh://git@myGITLABserver/myGROUP/myPROJECT.git</connection><developerConnection>scm:git:ssh://git@myGITLABserver/myGROUP/myPROJECT.git</developerConnection>

           

          It doesn't mean much, but I have a similar setup using 1.X Jenkins interacting with GitHub and things work as they should.

           

           

          Thanks for everything.

          Ron

           

          ron swanson added a comment - I am at Jenkins ver  2.46.2 https://plugins.jenkins.io/gitlab-plugin   1.4.7 https://plugins.jenkins.io/workflow-scm-step 2.5    My test case was: -Pipeline job that checked out single Jenkinsfile -"Poll SCM" was checked, but schedule was empty -"Triggered builds remotely (eg from scripts)"  and I set a Authentication token -Gitlab has this trigger for my job: http://myserver:8080/job/test.infinite.loop/build?token=mytoken -Tried the exclude logic from the job config in UI, as well as from in Jenkinsfile using "checkout scm". -My Jenkinsfile calls these maven commands to simulate a release: versions:set, versions:commit, scm:add and scm:checkin, which just updates the pom.xml file with the next version.     I tested every combination I could think of. Setting different user.name at checkout time using additional behaviour, changing displayname as defined in /etc/passwd, adding multiple users to exclude list, trying logic at job level, and in pipeline using 'checkout SCM'. Something to note is Jenkins reports the job was triggered by the user  'jenkins' as that is the user Jenkins is running as, but the user that checks into GIT is what is defined as the display name from /etc/passwd file.  So I am not exactly sure what user it SHOULD be expecting to try to exclude, but I have tried to exclude all the different users, individually as well as in a multiple list.   This is from  the "Changes" link in a particular build and shows that 'jenkins' did it, as 'jenkins' is the unix user that Jenkins is running under. * Commit f3b85jh3jh4k3j4h5kj3h45kj2k3j2bfc9c99727c566ba718c2 by *jenkins    [ci-skip] updating pom to 2017.08.427   But in GITLAB, the checkin comment shows the user that is defined as the display name in the /etc/passwd file for the user.  I have also tried changing that displayname to match the actual username, so it is the same value on both sides, to no avail.    [ci-skip] updating pom to 2017.08.427    CMJenkins committed 2 minutes ago   In my pom i use these GIT connection urls, so I have an SSH key setup between the user jenkins is running as, and the user we are connecting to GIT with, which is a different user, (and I've  tried to exclude that one too)   <connection>scm:git:ssh://git@myGITLABserver/myGROUP/myPROJECT.git</connection><developerConnection>scm:git:ssh://git@myGITLABserver/myGROUP/myPROJECT.git</developerConnection>   It doesn't mean much, but I have a similar setup using 1.X Jenkins interacting with GitHub and things work as they should.     Thanks for everything. Ron  

          Nikhil Sidhaye added a comment - - edited

          Do we have any way to git with include / exclude path for polling in pipeline? Because from pipeline syntax, I could not able to add exclude / include path behavior. Is this functionality is missing in pipeline? Even in simple scripted pipeline? 

           

           

          killdash9: Did you able to test this with pipeline with git? How did you configure it? Can you share your working pipeline syntax? 

          Nikhil Sidhaye added a comment - - edited Do we have any way to git with include / exclude path for polling in pipeline? Because from pipeline syntax, I could not able to add exclude / include path behavior. Is this functionality is missing in pipeline? Even in simple scripted pipeline?      killdash9 : Did you able to test this with pipeline with git? How did you configure it? Can you share your working pipeline syntax? 

          Michael Andrews added a comment - - edited

          nsidhaye It is not missing. You just need to use the full SCM step, and then use the extensions attribute.

          checkout([
              $class: 'GitSCM',
              branches: [
                  [
                      name: gitBranch
                  ]
              ],
              doGenerateSubmoduleConfigurations: false,
              extensions: [
                  [
                      $class: 'UserExclusion',
                      excludedUsers: """${scmPollingUserExclusions}"""
                  ],
                  [
                      $class: 'PathRestriction',
                      excludedRegions: scmPollingPathExclusions, 
                      includedRegions: scmPollingPathInclusions
                  ]
              ],

              ...

           

          Where,  scmPollingUserExclusions,  scmPollingPathExclusions, and  scmPollingPathInclusions are pipeline parameters.

           

           

          Michael Andrews added a comment - - edited nsidhaye It is not missing. You just need to use the full SCM step, and then use the extensions attribute. checkout([     $class: 'GitSCM',     branches: [         [             name: gitBranch         ]     ],     doGenerateSubmoduleConfigurations: false,     extensions: [         [             $class: 'UserExclusion',             excludedUsers: """${scmPollingUserExclusions}"""         ],         [             $class: 'PathRestriction',             excludedRegions: scmPollingPathExclusions,              includedRegions: scmPollingPathInclusions         ]     ],     ...   Where,  scmPollingUserExclusions,  scmPollingPathExclusions, and  scmPollingPathInclusions are pipeline parameters.    

          Xiaohui Cui added a comment -

          Using v3.9.1 version of this plugin, I tried killdash9 suggestion about using pipeline parameters (scmPollingPathInclusions, "$scmPollingPathInclusions", "${scmPollingPathInclusions}", '$scmPollingPathInclusions'), and no luck so far. Also tried adding [$class: 'DisableRemotePoll'], job was still triggered on a region outside of the specified IncludedRegion.

          However, the region inclusion/exclusion works in freestyle jobs. Any plan to have this fixed soon? 

           

          Pipeline - does not work

          [$class: 'PathRestriction', [$class: 'PathRestriction', excludedRegions: '', includedRegions: 'src/.*']]

           

          Freestyle - works

           

          Xiaohui Cui added a comment - Using v3.9.1 version of this plugin, I tried killdash9 suggestion about using pipeline parameters (scmPollingPathInclusions, "$scmPollingPathInclusions", "${scmPollingPathInclusions}", '$scmPollingPathInclusions'), and no luck so far. Also tried adding [$class: 'DisableRemotePoll'] , job was still triggered on a region outside of the specified IncludedRegion. However, the region inclusion/exclusion works in freestyle jobs. Any plan to have this fixed soon?    Pipeline - does not work [$class: 'PathRestriction', [$class: 'PathRestriction', excludedRegions: '', includedRegions: 'src/.*'] ]   Freestyle - works  

          Mark Waite added a comment -

          scui no plans from me to fix it soon. There were discussions between jglick and stephenconnolly of techniques that might work to add region exclusion to the SCM API and then allow that region exclusion to be used by the git plugin and other SCM plugins. However, there has been no implementation of those discussions and I don't expect any implementation of those discussions in the near future.

          Mark Waite added a comment - scui no plans from me to fix it soon. There were discussions between jglick and stephenconnolly of techniques that might work to add region exclusion to the SCM API and then allow that region exclusion to be used by the git plugin and other SCM plugins. However, there has been no implementation of those discussions and I don't expect any implementation of those discussions in the near future.

          You need to use regular expressions - not glob style pattern matching. E.g., ^foo\/bar\/.*$ for all files in the /foo/bar directory. 

          Michael Andrews added a comment - You need to use regular expressions - not glob style pattern matching. E.g., ^foo\/bar\/.*$ for all files in the /foo/bar directory. 

          ...and be sure to escape the separator as shown in the previous comment.

          Michael Andrews added a comment - ...and be sure to escape the separator as shown in the previous comment.

          Xiaohui Cui added a comment - - edited

          markewaite and killdash9, thanks for the reply.

           

          FYI, I did more testing and seems like the regular expression does not make any difference. To simplify the paths to include, I limited to the README.md in the root folder. Again, the freestyle job was triggered correctly but pipeline job did not trigger correctly (as in changing to any file in the repo would trigger).

           

          Works:

           

          Does not work:

          [$class: 'PathRestriction', excludedRegions: '', includedRegions: 'README.md']

          [$class: 'PathRestriction', excludedRegions: '', includedRegions: "README.md"]

          [$class: 'PathRestriction', excludedRegions: '', includedRegions: '^README.md\$']

          [$class: 'PathRestriction', excludedRegions: '', includedRegions: "^README.md\$"]

           

          I even tried to use the pipeline syntax function on jenkins to make sure that I got the syntax correct. And I got exactly this line which did not work.

          [$class: 'PathRestriction', excludedRegions: '', includedRegions: 'README.md']

          No luck finding a workaround yet...

           

          Xiaohui Cui added a comment - - edited markewaite and killdash9 , thanks for the reply.   FYI, I did more testing and seems like the regular expression does not make any difference. To simplify the paths to include, I limited to the README.md in the root folder. Again, the freestyle job was triggered correctly but pipeline job did not trigger correctly (as in changing to any file in the repo would trigger).   Works:   Does not work: [$class: 'PathRestriction', excludedRegions: '', includedRegions: 'README.md'] [$class: 'PathRestriction', excludedRegions: '', includedRegions: "README.md"] [$class: 'PathRestriction', excludedRegions: '', includedRegions: '^README.md\$'] [$class: 'PathRestriction', excludedRegions: '', includedRegions: "^README.md\$"]   I even tried to use the pipeline syntax function on jenkins to make sure that I got the syntax correct. And I got exactly this line which did not work. [$class: 'PathRestriction', excludedRegions: '', includedRegions: 'README.md'] No luck finding a workaround yet...  

          Did you try escaping the dot?  

          README\.md

          or

          ^README\.md$

           

          M

          Michael Andrews added a comment - Did you try escaping the dot?   README\.md or ^README\.md$   M

          You should use an online regex tester to make sure your expressions is correct before attempting to use the pattern in Jenkins.  https://regex101.com 

          Michael Andrews added a comment - You should use an online regex tester to make sure your expressions is correct before attempting to use the pattern in Jenkins.   https://regex101.com  

          Xiaohui Cui added a comment - - edited

          Need to double escape the backslash. Just tried the following and all triggered by change to another file file in the repo.

          'README\\.md'
          "README\\.md"
          '^README\\.md$'
          '^README\\.md\$'
          

          killdash9, and thanks for the reminder about the dot. But the dot in regex would match "." anyways?

          Xiaohui Cui added a comment - - edited Need to double escape the backslash. Just tried the following and all triggered by change to another file file in the repo. 'README\\.md' "README\\.md" '^README\\.md$' '^README\\.md\$' killdash9 , and thanks for the reminder about the dot. But the dot in regex would match "." anyways?

          Shaul Lahav added a comment - - edited

          What is causing the problem is that when the Git CLI client calls the "git log" command giving it a range of revisions to filter by (last build's most recent revision to the latest committed revision), all files in the repo/tree are returned instead of just the newly committed file(s).

          Example:
          I committed a file named "dir2/README8", and when Jenkins polled the SCM, it invoked:

          git log --full-history --no-abbrev --format=raw -M -m --raw 645221fb9fb8b752db7736d40c4c311e032482bb..d36267d8d88bdd085c894f35b1585a9f1ee9d755 # timeout=10
          

          Which resulted in the following output:

          commit d36267d8d88bdd085c894f35b1585a9f1ee9d755
          tree 6efc76859dbd9dee1afd6881f81d2c0aad574168
          parent 645221fb9fb8b752db7736d40c4c311e032482bb
          author Shaul Lahav <slahav@company.com> 1532602858 +0300
          committer Shaul Lahav <slahav@company.com> 1532602858 +0300
              new file8
          :000000 100644 0000000000000000000000000000000000000000 576c717174a2f49675f4b57429424e3d54cf2a07 A README.md
          :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A dir1/README2
          :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A dir2/README8

          Notice that other, unchanged files, also appear in the output.

          However, When I ran the same command not from Jenkins, I got:

          {{}}

           

          commit d36267d8d88bdd085c894f35b1585a9f1ee9d755
          tree 6efc76859dbd9dee1afd6881f81d2c0aad574168
          parent 645221fb9fb8b752db7736d40c4c311e032482bb
          author Shaul Lahav <slahav@company.com> 1532602858 +0300
          committer Shaul Lahav <slahav@company.com> 1532602858 +0300
              new file8
          :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A      dir2/README8
          

          {{}}
          Which is the expected result.

          This is turn causes the PathRestriction extension to iterate all these files instead of only the relevant ones, which means that if at least one of these files matches the "included" regions pattern (I made it so only the "dir1/.*" path is included), it will return PollingResult.SIGNIFICANT instead of PollingResult.NO_CHANGES.

          I verified that Jenkins is using the same git client I used in the command line, which is the one found in the path.
          I can't think of any explanation for this.
          Any ideas??

          Shaul Lahav added a comment - - edited What is causing the problem is that when the Git CLI client calls the " git log " command giving it a range of revisions to filter by (last build's most recent revision to the latest committed revision), all files in the repo/tree are returned instead of just the newly committed file(s). Example: I committed a file named "dir2/README8", and when Jenkins polled the SCM, it invoked: git log --full-history --no-abbrev --format=raw -M -m --raw 645221fb9fb8b752db7736d40c4c311e032482bb..d36267d8d88bdd085c894f35b1585a9f1ee9d755 # timeout=10 Which resulted in the following output: commit d36267d8d88bdd085c894f35b1585a9f1ee9d755 tree 6efc76859dbd9dee1afd6881f81d2c0aad574168 parent 645221fb9fb8b752db7736d40c4c311e032482bb author Shaul Lahav <slahav@company.com> 1532602858 +0300 committer Shaul Lahav <slahav@company.com> 1532602858 +0300     new file8 :000000 100644 0000000000000000000000000000000000000000 576c717174a2f49675f4b57429424e3d54cf2a07 A README.md :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A dir1/README2 :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A dir2/README8 Notice that other, unchanged files, also appear in the output. However, When I ran the same command not from Jenkins, I got: {{}}   commit d36267d8d88bdd085c894f35b1585a9f1ee9d755 tree 6efc76859dbd9dee1afd6881f81d2c0aad574168 parent 645221fb9fb8b752db7736d40c4c311e032482bb author Shaul Lahav <slahav@company.com> 1532602858 +0300 committer Shaul Lahav <slahav@company.com> 1532602858 +0300     new file8 :000000 100644 0000000000000000000000000000000000000000 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A      dir2/README8 {{}} Which is the expected result. This is turn causes the PathRestriction extension to iterate all these files instead of only the relevant ones, which means that if at least one of these files matches the "included" regions pattern (I made it so only the "dir1/.*" path is included), it will return PollingResult.SIGNIFICANT instead of PollingResult.NO_CHANGES. I verified that Jenkins is using the same git client I used in the command line, which is the one found in the path. I can't think of any explanation for this. Any ideas??

          Allan BURDAJEWICZ added a comment - - edited

          I was able to reproduce this easily and also to find a workaround.

          Reproduce

          I have the repo "user/repoA" that have the following Jenkinsfile:

          node {
              deleteDir()
          
              dir("repoA") {
                  checkout scm: [$class: 'GitSCM', 
                      branches: [[name: 'master']], 
                      extensions: [[$class: 'UserExclusion', excludedUsers: 'jenkinsbot']], 
                      userRemoteConfigs: [[credentialsId: 'mycredentials', url: 'https://1q2w3e4r5t6y7u8i9o@github.example.com/user/repoA.git']]]
              }
              
              dir("repoB") {
                  checkout changelog: false, poll: false, scm: [$class: 'GitSCM', 
                      branches: [[name: 'master']], 
                      extensions: [[$class: 'IgnoreNotifyCommit']], 
                      userRemoteConfigs: [[credentialsId: 'mycredentials', url: 'https://1q2w3e4r5t6y7u8i9o@github.example.com/user/repoB.git']]
                  ]
              }
              
              dir('repoB') {
                  try {
                      sh "git checkout master"
                      sh "git config --global user.name 'jenkinsbot'"
                      sh "git config --global user.email 'jenkinsbot@example.com'"
                      sh "echo ${JOB_NAME}/${BUILD_NUMBER} > test.txt"
                      sh "git add ."
                      sh "git commit -m 'Automated: Updating test.txt during build'"
                      sh "git push"
                  } catch (err) {
                      echo "No change in test.txt"
                  }
              }
          }
          

          The Pipeline jobs looks like the following:

          Expected Behavior

          Achange to "repoA" and "repoB" should trigger polling.
          Polling should ignore "repoA" commits from the "jenkinsbot" user.
          Polling should ignore "repoB".

          Actual Behavior

          So a change to "repoA" and "repoB" should trigger polling.
          Polling should ignore "repoA" commits from the "jenkinsbot" user.
          Polling should ignore "repoB".

          In that particular case, because the user exclusion doe snot work the job builds in loop...

          Workaround

          The workaround is to set the User Exclusion in the Pipeline Definition SCM instead of inside the Jenkinsfile. Doing the following fix this scenario:

          Note: This is not required but in this case it makes sense anyway to use checkout scm in the Jenkinsfile.

          ****

          So it seems that the problem come from polling rules of the SCMs defined in checkout steps (vs. SCM definition in the Pipeline job). This workaround works in a scenario where the the commits that must be ignored are from the repository holding the Jenkinsfile. I have not tested a scenario where the polling rules are set to "repoB" with "poll: true".

          I am hoping this helps to find the root cause here.

          Allan BURDAJEWICZ added a comment - - edited I was able to reproduce this easily and also to find a workaround. Reproduce I have the repo "user/repoA" that have the following Jenkinsfile: node { deleteDir() dir( "repoA" ) { checkout scm: [$class: 'GitSCM' , branches: [[name: 'master' ]], extensions: [[$class: 'UserExclusion' , excludedUsers: 'jenkinsbot' ]], userRemoteConfigs: [[credentialsId: 'mycredentials' , url: 'https: //1q2w3e4r5t6y7u8i9o@github.example.com/user/repoA.git' ]]] } dir( "repoB" ) { checkout changelog: false , poll: false , scm: [$class: 'GitSCM' , branches: [[name: 'master' ]], extensions: [[$class: 'IgnoreNotifyCommit' ]], userRemoteConfigs: [[credentialsId: 'mycredentials' , url: 'https: //1q2w3e4r5t6y7u8i9o@github.example.com/user/repoB.git' ]] ] } dir( 'repoB' ) { try { sh "git checkout master" sh "git config --global user.name 'jenkinsbot' " sh "git config --global user.email 'jenkinsbot@example.com' " sh "echo ${JOB_NAME}/${BUILD_NUMBER} > test.txt" sh "git add ." sh "git commit -m 'Automated: Updating test.txt during build' " sh "git push" } catch (err) { echo "No change in test.txt" } } } The Pipeline jobs looks like the following: Expected Behavior Achange to "repoA" and "repoB" should trigger polling. Polling should ignore "repoA" commits from the "jenkinsbot" user. Polling should ignore "repoB". Actual Behavior So a change to "repoA" and "repoB" should trigger polling. Polling should ignore "repoA" commits from the "jenkinsbot" user. Polling should ignore "repoB". In that particular case, because the user exclusion doe snot work the job builds in loop... Workaround The workaround is to set the User Exclusion in the Pipeline Definition SCM instead of inside the Jenkinsfile . Doing the following fix this scenario: Note: This is not required but in this case it makes sense anyway to use checkout scm in the Jenkinsfile. **** So it seems that the problem come from polling rules of the SCMs defined in checkout steps (vs. SCM definition in the Pipeline job). This workaround works in a scenario where the the commits that must be ignored are from the repository holding the Jenkinsfile. I have not tested a scenario where the polling rules are set to "repoB" with "poll: true". I am hoping this helps to find the root cause here.

          Are there plans to address this?

          Working with a scripted pipeline it's possible to define polling as follows

          properties(
              [ 
                  pipelineTriggers([
                      [$class: "SCMTrigger", scmpoll_spec: "H/5 * * * *"],
                  ]) 
              ]
          )
          

          It would be very handy to be able to specify, includes / excludes at this level

          Ric Featherstone added a comment - Are there plans to address this? Working with a scripted pipeline it's possible to define polling as follows properties( [ pipelineTriggers([ [$class: "SCMTrigger" , scmpoll_spec: "H/5 * * * *" ], ]) ] ) It would be very handy to be able to specify, includes / excludes at this level

          Mark Waite added a comment -

          There have been some brief discussions about it, but there are no plans to address it.

          Mark Waite added a comment - There have been some brief discussions about it, but there are no plans to address it.

          Hi, I think I have the same issue, PathRestriction/includedRegions defined in Jenkinsfile does not work:
          "[$class: 'PathRestriction', excludedRegions: '', includedRegions: '<included-directory>/.*']"
          It seems that Jenkins Polling log says correctly that commit to other folder than 'includedRegions' is ignored, but still the build is started by scm change. Clip from Polling log:

          "Ignored commit afa14f5970cdaa2d3d3a96f0c76cabf3aa2928dc: No paths matched included region whitelist"

          However PathRestriction/includedRegions seems to work at least in Jenkins Freestyle project when configuring restriction in Jenkins GUI.
          But why this issue type is "Improvement", I consider this a bug?

          Jari Heikkilä added a comment - Hi, I think I have the same issue, PathRestriction/includedRegions defined in Jenkinsfile does not work: " [$class: 'PathRestriction', excludedRegions: '', includedRegions: '<included-directory>/.*'] " It seems that Jenkins Polling log says correctly that commit to other folder than 'includedRegions' is ignored, but still the build is started by scm change. Clip from Polling log: "Ignored commit afa14f5970cdaa2d3d3a96f0c76cabf3aa2928dc: No paths matched included region whitelist" However PathRestriction/includedRegions seems to work at least in Jenkins Freestyle project when configuring restriction in Jenkins GUI. But why this issue type is "Improvement", I consider this a bug?

          smek added a comment -

          Does this issue also aim to solve the issue where you can't poll multiple git repository with pipeline jobs?

          smek added a comment - Does this issue also aim to solve the issue where you can't poll multiple git repository with pipeline jobs?

          Kyle Leinen added a comment - - edited

          From reading the original ticket notes along with the responses, I think this one is more in alignment with special rules around a single repository and not multiple repos.

          Kyle Leinen added a comment - - edited From reading the original ticket notes along with the responses, I think this one is more in alignment with special rules around a single repository and not multiple repos.

          Jackie Xiao added a comment -

          For multibranch pipeline jobs, are there any workarounds for Subversion with the 'checkout' step (includedRegions/excludedRegions)?

          Something like: 

          def scm = checkout scm: [

            $class:'SubversionSCM',
            extensions: [
              [$class: 'PathRestriction', excludedRegions: '', includedRegions: '.+\\.java']
            ]
          ]

          Jackie Xiao added a comment - For multibranch pipeline jobs, are there any workarounds for Subversion with the 'checkout' step (includedRegions/excludedRegions)? Something like:  def scm = checkout scm: [   $class:'SubversionSCM',   extensions: [     [$class: 'PathRestriction', excludedRegions: '', includedRegions: '.+\\.java']   ] ]

          Kishore Babu Kavuru added a comment - - edited

          Pipeline builds on every polling without any update in SCM..

          It seems if there any issue in the pipeline script, Then it is continuously building the pipeline as per polling.

          Kishore Babu Kavuru added a comment - - edited Pipeline builds on every polling without any update in SCM.. It seems if there any issue in the pipeline script, Then it is continuously building the pipeline as per polling.

          Szymon Seget added a comment -

          Hi, any updates? I need this feature to work. kishore_1269 are you trying to fix it?

          Szymon Seget added a comment - Hi, any updates? I need this feature to work. kishore_1269 are you trying to fix it?

          Carol Lim added a comment - - edited

          Hi, does anyone able to get the excludedRegions and includedRegions to work in a pipeline job?

          Carol Lim added a comment - - edited Hi, does anyone able to get the excludedRegions and includedRegions to work in a pipeline job?

          Andrii added a comment -

          +1, I have the same problem. Build of pipeline job is triggered despite of commit to path that specified in "Polling ignore commits in certain path" in job configuration (not inside Jenkinsfile)

           

          Andrii added a comment - +1, I have the same problem. Build of pipeline job is triggered despite of commit to path that specified in "Polling ignore commits in certain path" in job configuration (not inside Jenkinsfile)  

          the assigned user kishore_1269 seems to have been inactive since november 2019. is there someone else who can pic up this issue?

          Stephan Schultchen added a comment - the assigned user kishore_1269 seems to have been inactive since november 2019. is there someone else who can pic up this issue?

          Mark Waite added a comment -

          schlitzered I'm not aware of anyone intending to work on this issue. As far as I'm concerned, the git plugin should not apply its settings to pipeline polling because pipeline polling is handled in the branch API and by extensions of the branch API.

          If you use a multibranch pipeline, then you can limit which jobs are created through the basic branch build strategies plugin and can limit the paths with the pipeline multibranch build strategies plugin.

          Mark Waite added a comment - schlitzered I'm not aware of anyone intending to work on this issue. As far as I'm concerned, the git plugin should not apply its settings to pipeline polling because pipeline polling is handled in the branch API and by extensions of the branch API. If you use a multibranch pipeline, then you can limit which jobs are created through the basic branch build strategies plugin and can limit the paths with the pipeline multibranch build strategies plugin .

          markewaite i am not using a Multibranch Pipeline, i am using a normal pipeline. and afaik this should work, it is just a bug, also normal pipeline jobs are not deprecated, so i do not see why i should switch.

           

          never the less, me and a colleague took a look at the problem, and we found the issue, and created a pull request & a another ticket:

          https://github.com/jenkinsci/git-plugin/pull/1046

          https://issues.jenkins.io/browse/JENKINS-64902

           

          so hopefully this issue will soon be fixed upstream

          Stephan Schultchen added a comment - markewaite i am not using a Multibranch Pipeline, i am using a normal pipeline. and afaik this should work, it is just a bug, also normal pipeline jobs are not deprecated, so i do not see why i should switch.   never the less, me and a colleague took a look at the problem, and we found the issue, and created a pull request & a another ticket: https://github.com/jenkinsci/git-plugin/pull/1046 https://issues.jenkins.io/browse/JENKINS-64902   so hopefully this issue will soon be fixed upstream

          Stanisław added a comment -

          Please start work on it. Thank you for fixing this issue, it's pending still.

          Stanisław added a comment - Please start work on it. Thank you for fixing this issue, it's pending still.

          Mark Waite added a comment -

          stanislaw_kodzis I don't plan to start work on this issue.

          If you'd like to continue the work that was started by schlitzered, you can use the code that was shared in https://github.com/jenkinsci/git-plugin/pull/1046 . If those changes resolve the issue for you, that would be a great reason to submit a pull request containing the changes. If those changes do not resolve the issue for you, the experience working with those changes may guide you to an improvement that will resolve the issue for you.

          Mark Waite added a comment - stanislaw_kodzis I don't plan to start work on this issue. If you'd like to continue the work that was started by schlitzered , you can use the code that was shared in https://github.com/jenkinsci/git-plugin/pull/1046 . If those changes resolve the issue for you, that would be a great reason to submit a pull request containing the changes. If those changes do not resolve the issue for you, the experience working with those changes may guide you to an improvement that will resolve the issue for you.

          don´t use my pull request, i have no clue about java, and just tried something, this pull request never worked.

          I myself, in the meantime, switched to Github Actions. the plugin situation with jenkins is a mess. way too much unmaintained code everywhere, and bugs that never get fixed :-/

          Stephan Schultchen added a comment - don´t use my pull request, i have no clue about java, and just tried something, this pull request never worked. I myself, in the meantime, switched to Github Actions. the plugin situation with jenkins is a mess. way too much unmaintained code everywhere, and bugs that never get fixed :-/

          Stanisław added a comment -

          Thanks for the info Mark and Stephan.

          So the GIT plugin needs to be rewritten from scratch? Becase now it too messy to refactor?

           

          Stanisław added a comment - Thanks for the info Mark and Stephan. So the GIT plugin needs to be rewritten from scratch? Becase now it too messy to refactor?  

            Unassigned Unassigned
            dvader Darth Vader
            Votes:
            108 Vote for this issue
            Watchers:
            109 Start watching this issue

              Created:
              Updated: