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

Regex build branch set ignores 'ignore user'

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Critical Critical
    • git-plugin
    • None
    • Jenkins Version: 1.6.45
      Git-Plugin Version: 2.4.[0-1]

      When specifying our branches, we use the regex:

      origin\/cs\/805-release\.*

      In the build step, we do an auto increment of the version and commit it.

      When the build commits, it triggers another build, and this continues endlessly.

      See attached photos.

      Possibly related to:
      JENKINS-32436

        1. build_config
          53 kB
        2. chain_building
          22 kB
        3. changes_list
          28 kB
        4. git_config
          52 kB

          [JENKINS-32577] Regex build branch set ignores 'ignore user'

          Mark Waite added a comment - - edited

          Thanks for the report. Unfortunately, I can't duplicate the bug as you've described, even while making guesses based on the pictures you attached.

          Here are the steps I used to create my test case job which shows that polling exclusions are honored for specific users when the users are specified correctly.

          1. Create a new freestyle project "JENKINS-32577-ignore-user-not-honored"
          2. Use Git as the SCM system, point to repository ssh://mwaite@mark-pc1.markwaite.net/var/lib/git/mwaite/bugs/JENKINS-26197.git (a locally maintained repository which has polling hooks already defined for my Jenkins server). The same repository is publicly mirrored as https://github.com/MarkEWaite/JENKINS-26197 (see the cs/release-1.0.0 branch)
          3. Configure the "Branches to build" as "cs/805-release-*" (since you said "regular expression, but didn't start the branch name with a ":", I assumed you weren't actually using a regular expression to describe the branch to build)
          4. Add the additional behavior "Polling ignores commits from certain users", add the user "Mark Waite - Jenkins" as the user to be ignored
          5. Add an "Invoke Ant" build step with the default goal (the default in that repo will increment the build number and commit it)
          6. Add a Git Publisher post build action to push the branch "cs/805-release-1.0.0" to target remote "origin"
          7. Enable SCM polling with the "Poll SCM" check box, either with no schedule (like I used - depend on the hook script to notify Jenkins) or with a schedule of your choice

          When I did that, the job correctly pushed changes to the origin repository, and only pushed them once. It also correctly detected changes which I made from another account and then pushed a single version number increment after my change.

          The post-receive hooks that I'm using in my local git repository are:

          for host in localhost debian8; do
  curl -s http://$host:8080/git/notifyCommit?url=git://mark-pc1/git/mwaite/bugs/JENKINS-26197.git
  curl -s http://$host:8080/git/notifyCommit?url=git://mark-pc1.markwaite.net/git/mwaite/bugs/JENKINS-26197.git
  curl -s http://$host:8080/git/notifyCommit?url=ssh://mark-pc1.markwaite.net/var/lib/git/mwaite/bugs/JENKINS-26197.git
  curl -s http://$host:8080/git/notifyCommit?url=ssh://mark-pc1/var/lib/git/mwaite/bugs/JENKINS-26197.git
  curl -s http://$host:8080/git/notifyCommit?url=mwaite@mark-pc1:/var/lib/git/mwaite/bugs/JENKINS-26197.git
  curl -s http://$host:8080/git/notifyCommit?url=mwaite@mark-pc1.markwaite.net:/var/lib/git/mwaite/bugs/JENKINS-26197.git
done

          If you're using a GitHub based webhook (rather than a post-receive hook), and if that GitHub webhook provides a sha1 parameter, then that may cause the build to run repeatedly. If a sha1 parameter is passed as part of the notify commit request, then the plugin assumes that you intend for that specific sha1 to be built, without considering any exclusions.

          Mark Waite added a comment - - edited Thanks for the report. Unfortunately, I can't duplicate the bug as you've described, even while making guesses based on the pictures you attached. Here are the steps I used to create my test case job which shows that polling exclusions are honored for specific users when the users are specified correctly. Create a new freestyle project " JENKINS-32577 -ignore-user-not-honored" Use Git as the SCM system, point to repository ssh://mwaite@mark-pc1.markwaite.net/var/lib/git/mwaite/bugs/JENKINS-26197.git (a locally maintained repository which has polling hooks already defined for my Jenkins server). The same repository is publicly mirrored as https://github.com/MarkEWaite/JENKINS-26197 (see the cs/release-1.0.0 branch) Configure the "Branches to build" as "cs/805-release-*" (since you said "regular expression, but didn't start the branch name with a ":", I assumed you weren't actually using a regular expression to describe the branch to build) Add the additional behavior "Polling ignores commits from certain users", add the user "Mark Waite - Jenkins" as the user to be ignored Add an "Invoke Ant" build step with the default goal (the default in that repo will increment the build number and commit it) Add a Git Publisher post build action to push the branch "cs/805-release-1.0.0" to target remote "origin" Enable SCM polling with the "Poll SCM" check box, either with no schedule (like I used - depend on the hook script to notify Jenkins) or with a schedule of your choice When I did that, the job correctly pushed changes to the origin repository, and only pushed them once. It also correctly detected changes which I made from another account and then pushed a single version number increment after my change. The post-receive hooks that I'm using in my local git repository are: for host in localhost debian8; do curl -s http://$host:8080/git/notifyCommit?url=git://mark-pc1/git/mwaite/bugs/JENKINS-26197.git curl -s http://$host:8080/git/notifyCommit?url=git://mark-pc1.markwaite.net/git/mwaite/bugs/JENKINS-26197.git curl -s http://$host:8080/git/notifyCommit?url=ssh://mark-pc1.markwaite.net/var/lib/git/mwaite/bugs/JENKINS-26197.git curl -s http://$host:8080/git/notifyCommit?url=ssh://mark-pc1/var/lib/git/mwaite/bugs/JENKINS-26197.git curl -s http://$host:8080/git/notifyCommit?url=mwaite@mark-pc1:/var/lib/git/mwaite/bugs/JENKINS-26197.git curl -s http://$host:8080/git/notifyCommit?url=mwaite@mark-pc1.markwaite.net:/var/lib/git/mwaite/bugs/JENKINS-26197.git done If you're using a GitHub based webhook (rather than a post-receive hook), and if that GitHub webhook provides a sha1 parameter, then that may cause the build to run repeatedly. If a sha1 parameter is passed as part of the notify commit request, then the plugin assumes that you intend for that specific sha1 to be built, without considering any exclusions.

            Unassigned Unassigned
            daemoen Marc Mercer
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: