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

Equivalent to polling commit exclusions for branch indexing

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • branch-api-plugin
    • None
    • Windows

      I have an organizational project configured which scans repositories for jenkinsfile. One of the repository (https://github.com/VirtoCommerce/vc-module-jenkinssample) has a following Jenkinsfile defined:

          node 
          {
          	stage 'Checkout'
                  checkout([
                      $class: 'GitSCM', 
                      branches: [[name: '*/master']], 
                      extensions: [[
          			    $class: 'PathRestriction', 
          			    excludedRegions: 'CommonAssemblyInfo\\.cs', 
          			    includedRegions: ''
          		    ]], 
                      userRemoteConfigs: [[
                          url: 'git@github.com:VirtoCommerce/vc-module-jenkinssample.git']]])
          }
      

      As you might see I have an excluded region defined, so changes made to CommonAssemblyInfo.cs don't trigger any builds. However "Branch Indexing" still forces the job to build when I commit changes to "CommonAssemblyInfo.cs". How can I prevent this?

      Btw, the above script works fine in a separate/individual Pipeline Job.

        1. multibranch_indexing_options.png
          multibranch_indexing_options.png
          182 kB
        2. non_multibranch_pipeline_filters.png
          non_multibranch_pipeline_filters.png
          147 kB
        3. screenshot-1.png
          screenshot-1.png
          2 kB
        4. screenshot-2.png
          screenshot-2.png
          95 kB
        5. workaround.txt
          0.9 kB

          [JENKINS-35988] Equivalent to polling commit exclusions for branch indexing

          Joshua Noble added a comment -

          I'm also looking for a way to exclude/ignore commits from a specific Git author. For example, an automated user who bumps the package.json version of an npm module. If that automated user pushes back to the repository after a build, that push will trigger yet another build. Is there a way to ignore/filter out events from certain commit authors? From what I can tell, the webhook events from GitHub include commit author information when a push occurs.

          Joshua Noble added a comment - I'm also looking for a way to exclude/ignore commits from a specific Git author. For example, an automated user who bumps the package.json version of an npm module. If that automated user pushes back to the repository after a build, that push will trigger yet another build. Is there a way to ignore/filter out events from certain commit authors? From what I can tell, the webhook events from GitHub include commit author information when a push occurs.

          Maxime Lemanissier added a comment - - edited

          I'm having a similar issue using pipeline library.

          When i merge a change on the master branch of my jenkins pipeline library, all jobs using this library (more than 100...) are all rebuilt simultaneously, which fills Jenkins queue for hours everytime a change is made on the library...

          This default behavior is probably well intended, as if the pipeline changes, all jobs using should be rebuilt, but when having a lot of jobs, this becomes unpractical/unusable. I would prefer to wait for the next manual build or SCM change on the project repository (not on the lib one) to trigger a new build.

          Is there a way to not trigger builds due to changes on the pipeline library?

          If not, can i use a specific naming convention for the master branch of the pipeline library, and excluding it from polling as shared in previous comment? Will this exclusion also apply on pipeline library?

          Maxime Lemanissier added a comment - - edited I'm having a similar issue using pipeline library. When i merge a change on the master branch of my jenkins pipeline library, all jobs using this library (more than 100...) are all rebuilt simultaneously, which fills Jenkins queue for hours everytime a change is made on the library... This default behavior is probably well intended, as if the pipeline changes, all jobs using should be rebuilt, but when having a lot of jobs, this becomes unpractical/unusable. I would prefer to wait for the next manual build or SCM change on the project repository (not on the lib one) to trigger a new build. Is there a way to not trigger builds due to changes on the pipeline library? If not, can i use a specific naming convention for the master branch of the pipeline library, and excluding it from polling as shared in previous comment? Will this exclusion also apply on pipeline library?

          Nate Faerber added a comment -

          I believe this is the feature I've been looking for.  It makes sense with the introduction of custom Jenkinsfile path to allow us to ignore changes that occur outside of the Jenkinsfile path.  Even that might be too restrictive.  It would solve a lot of people's problems if we can just specific the subdirectory we want to poll.  This would allow folks to put their Jenkinsfiles in completely different paths.

          Nate Faerber added a comment - I believe this is the feature I've been looking for.  It makes sense with the introduction of custom Jenkinsfile path to allow us to ignore changes that occur outside of the Jenkinsfile path.  Even that might be too restrictive.  It would solve a lot of people's problems if we can just specific the subdirectory we want to poll.  This would allow folks to put their Jenkinsfiles in completely different paths.

          Nathan Lowe added a comment -

          We'd love to see this as well. The closest I can get now is a step that scripts the currentBuild.result to ABORTED and fail the build. This shows up as skipped in some places:

          But failed in others:

          And jenkins reports the build as failed to Bitbucket.

          Nathan Lowe added a comment - We'd love to see this as well. The closest I can get now is a step that scripts the currentBuild.result to ABORTED and fail the build. This shows up as skipped in some places: But failed in others: And jenkins reports the build as failed to Bitbucket.

          any update on this?

          Andreas Sieferlinger added a comment - any update on this?

          Torben Knerr added a comment -

          +1 to what leedega mentioned above. "Polling ignores commits in certain paths" is available for "normal" Pipelines, just not for Multibranch Pipelines.

          jglick any chance the extension to scm-api you mentioned in https://issues.jenkins-ci.org/browse/JENKINS-35988?focusedCommentId=295310&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-295310 are on the roadmap?

          (in my case, it would even be for the bitbucket-branch-source-plugin....)

          Torben Knerr added a comment - +1 to what leedega mentioned above. "Polling ignores commits in certain paths" is available for "normal" Pipelines, just not for Multibranch Pipelines. jglick any chance the extension to scm-api you mentioned in https://issues.jenkins-ci.org/browse/JENKINS-35988?focusedCommentId=295310&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-295310 are on the roadmap? (in my case, it would even be for the bitbucket-branch-source-plugin....)

          Liam Newman added a comment - - edited

          Liam Newman added a comment - - edited acejam Ignore by commiter: https://github.com/jenkinsci/ignore-committer-strategy-plugin tknerr webrat woland nlowe_hyland natefaerber leedega I think this does what is being requested here: https://wiki.jenkins.io/display/JENKINS/Multibranch+Build+Strategy+Extension+Plugin

          Liam Newman added a comment -

          Resolving for now based on existing plugin. Please comment if not done.

          Liam Newman added a comment - Resolving for now based on existing plugin. Please comment if not done.

          Bryce Schober added a comment -

          bitwiseman Note that the ignore-committer-strategy plugin doesn't support simple (non-email) subversion usernames, and at least superficially (at least in its UI wording) only supports Git. See also JENKINS-57474.

          Bryce Schober added a comment - bitwiseman Note that the ignore-committer-strategy plugin doesn't support simple (non-email) subversion usernames, and at least superficially (at least in its UI wording) only supports Git. See also JENKINS-57474 .

          Liam Newman added a comment -

          bryceman
          Thanks for filing a new JIRA for that issue.

          Liam Newman added a comment - bryceman Thanks for filing a new JIRA for that issue.

            bitwiseman Liam Newman
            woland Alexander Siniouguine
            Votes:
            32 Vote for this issue
            Watchers:
            40 Start watching this issue

              Created:
              Updated:
              Resolved: