• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None
    • Jenkins 1.509.4
      Git Plugin 2.0

      I found a case where the inverse build strategy built the wrong branch. Perhaps this is expected behavior in this case. It is kind of an odd case.

      • create git repo with master branch
      • create new job cloning git repository, leave everything at the default
      • build the job - builds master as expected
      • create branch b1 in git repo
      • change the configuration to be inverse
      • wipe out the workspace
      • build the job - builds master instead of b1

      Here's the output of the job:

      Started by user Jon Schewe
      Building in workspace /home/hudson/.hudson/jobs/test/workspace
      Cloning the remote Git repository
      Cloning repository /home/jpschewe/tmp/test-git
      Fetching upstream changes from /home/jpschewe/tmp/test-git
      Seen branch in repository origin/b1
      Seen branch in repository origin/master
      Seen 2 remote branches
      No new revisions were found; the most-recently built branch will be built again.
      Checking out Revision 88c6fdc580e0476c06bab09d872bbfeb625e58c2 (origin/master)
      [workspace] $ /bin/sh -xe /tmp/hudson6219937155460885978.sh
      + env
      BUILD_URL=http://mtu.net/jenkins/job/test/5/
      HUDSON_SERVER_COOKIE=6c6746aa04dc140a
      SHELL=/bin/sh
      TERM=screen
      XDG_SESSION_COOKIE=d1dab2177f9c573e5fae0e004864cf15-1388974748.816383-1116830797
      BUILD_TAG=jenkins-test-5
      GIT_PREVIOUS_COMMIT=88c6fdc580e0476c06bab09d872bbfeb625e58c2
      ANT_HOME=/usr/local/ant/apache-ant-1.7.1
      WORKSPACE=/home/hudson/.hudson/jobs/test/workspace
      JOB_URL=http://mtu.net/jenkins/job/test/
      USER=hudson
      LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arj=01;31:.taz=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.zip=01;31:.z=01;31:.Z=01;31:.dz=01;31:.gz=01;31:.lz=01;31:.xz=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.jpg=01;35:.jpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.axv=01;35:.anx=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.axa=00;36:.oga=00;36:.spx=00;36:.xspf=00;36:
      GIT_COMMIT=88c6fdc580e0476c06bab09d872bbfeb625e58c2
      JENKINS_HOME=/home/hudson/.hudson
      PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/ant/apache-ant-1.7.1/bin:/usr/lib/iceweasel
      MAIL=/var/mail/hudson
      _=/usr/bin/env
      PWD=/home/hudson/.hudson/jobs/test/workspace
      HUDSON_URL=http://mtu.net/jenkins/
      LANG=en_US.UTF-8
      JOB_NAME=test
      JENKINS_URL=http://mtu.net/jenkins/
      BUILD_ID=2014-01-07_20-57-52
      HISTCONTROL=ignoredups
      HOME=/home/hudson
      SHLVL=3
      GIT_BRANCH=origin/master
      JENKINS_SERVER_COOKIE=6c6746aa04dc140a
      EXECUTOR_NUMBER=0
      GIT_URL=/home/jpschewe/tmp/test-git
      NODE_LABELS=master
      LOGNAME=hudson
      HUDSON_HOME=/home/hudson/.hudson
      NODE_NAME=master
      LESSOPEN=| /usr/bin/lesspipe %s
      BUILD_NUMBER=5
      HUDSON_COOKIE=5cd023e7-de24-4667-8339-dda542b76b67
      LESSCLOSE=/usr/bin/lesspipe %s %s
      + echo here
      here
      Finished: SUCCESS

          [JENKINS-21264] inverse build strategy issues

          Mark Waite added a comment - - edited

          I was able to duplicate the behavior reported here.

          I assume that the message "No new revisions were found; the most-recently built branch will be built again" is relevant to this case. I assume that since the plugin decided there were no changes on any branches, it built the last branch again, rather than applying the selected inverse branch choosing strategy.

          The steps I took:

          1. Create a new freestyle project
          2. Configure it to use Git as SCM with a nearby git:// protocol repository
          3. Add the branch choosing strategy, set it to "Inverse"
          4. Add an SCM poll every two minutes setting to the job
          5. Save the job - Confirm the job ran multiple times, once for each branch not named "master"
          6. Modify the branch choosing strategy to default
          7. Run the job - confirm it builds the master branch
          8. Modify the branch choosing strategy to Inverse
          9. Run the job - confirm it incorrectly builds the master branch again

          After that sequence of verification steps, I then submitted a change to the master branch while the inverse choosing strategy was enabled. I did not expect any build, since the change was to the branch which should have been excluded by the "Inverse" choosing strategy. I was surprised. It built and reported that there were no changes so it was buidling the same version again. I assume that is because the fast remote polling does not support the inverse branch choosing strategy.

          I added "Force polling with workspace" and submitted another change to the master branch. That did not cause a build. I submitted a change to another branch, and that caused a rebuild. It appears "Force polling with workspace" may need to be implicitly enabled if the inverse branch choosing strategy is enabled.

          Mark Waite added a comment - - edited I was able to duplicate the behavior reported here. I assume that the message "No new revisions were found; the most-recently built branch will be built again" is relevant to this case. I assume that since the plugin decided there were no changes on any branches, it built the last branch again, rather than applying the selected inverse branch choosing strategy. The steps I took: Create a new freestyle project Configure it to use Git as SCM with a nearby git:// protocol repository Add the branch choosing strategy, set it to "Inverse" Add an SCM poll every two minutes setting to the job Save the job - Confirm the job ran multiple times, once for each branch not named "master" Modify the branch choosing strategy to default Run the job - confirm it builds the master branch Modify the branch choosing strategy to Inverse Run the job - confirm it incorrectly builds the master branch again After that sequence of verification steps, I then submitted a change to the master branch while the inverse choosing strategy was enabled. I did not expect any build, since the change was to the branch which should have been excluded by the "Inverse" choosing strategy. I was surprised. It built and reported that there were no changes so it was buidling the same version again. I assume that is because the fast remote polling does not support the inverse branch choosing strategy. I added "Force polling with workspace" and submitted another change to the master branch. That did not cause a build. I submitted a change to another branch, and that caused a rebuild. It appears "Force polling with workspace" may need to be implicitly enabled if the inverse branch choosing strategy is enabled.

          jpschewe added a comment -

          I've also found that if the notify commit hook is passed a branch name a build never occurs because the branch name isn't found in the list of branches used for the job.

          http://mtu.net/jenkins/git/notifyCommit?url=https%3A%2F%2Fgithub.com%2Fjpschewe%2Ffll-sw&from=github&branches=ticket.20.ajax-playoffs
          No git jobs using repository: https://github.com/jpschewe/fll-sw and branches: ticket.20.ajax-playoffs
          No git consumers for URI https://github.com/jpschewe/fll-sw

          jpschewe added a comment - I've also found that if the notify commit hook is passed a branch name a build never occurs because the branch name isn't found in the list of branches used for the job. http://mtu.net/jenkins/git/notifyCommit?url=https%3A%2F%2Fgithub.com%2Fjpschewe%2Ffll-sw&from=github&branches=ticket.20.ajax-playoffs No git jobs using repository: https://github.com/jpschewe/fll-sw and branches: ticket.20.ajax-playoffs No git consumers for URI https://github.com/jpschewe/fll-sw

          Jonathan Brecher added a comment - - edited

          I spent a while trying to follow the "No new revisions were found; the most-recently built branch will be built again" lead.

          As far as I can tell, Jenkins seems to be hitting a code path where it believes that it isn't polling, and that it was told that it has to build something (as if someone clicked the Build Now link). Specifically, I think it’s reaching the determineRevisionToBuild() method at line 790 of https://github.com/jenkinsci/git-plugin/blob/616da8a1124b103c351e275540bce6eec9ce2959/src/main/java/hudson/plugins/git/GitSCM.java, which calls getBuildChooser().getCandidateRevisions() with a first parameter of false, indicating that it is NOT in a polling codepath. It seems that it most likely is getting there from the checkout() method at line 887, but I couldn't trace any further than that.

          Is this enough of a lead for someone (more familiar with the Jenkins codebase than I am) to figure out why polling might be hitting a code path that eventually calls getBuildChooser().getCandidateRevisions() with a parameter that says it is not polling?

          Jonathan Brecher added a comment - - edited I spent a while trying to follow the "No new revisions were found; the most-recently built branch will be built again" lead. As far as I can tell, Jenkins seems to be hitting a code path where it believes that it isn't polling, and that it was told that it has to build something (as if someone clicked the Build Now link). Specifically, I think it’s reaching the determineRevisionToBuild() method at line 790 of https://github.com/jenkinsci/git-plugin/blob/616da8a1124b103c351e275540bce6eec9ce2959/src/main/java/hudson/plugins/git/GitSCM.java , which calls getBuildChooser().getCandidateRevisions() with a first parameter of false, indicating that it is NOT in a polling codepath. It seems that it most likely is getting there from the checkout() method at line 887, but I couldn't trace any further than that. Is this enough of a lead for someone (more familiar with the Jenkins codebase than I am) to figure out why polling might be hitting a code path that eventually calls getBuildChooser().getCandidateRevisions() with a parameter that says it is not polling?

          I ran into this bug in Jenkins 1.553

          I tried the "workaround": Inverse selection strategy and Force polling with workspace. I get this in the Git polling log when I push change to a non-master branch:

          Started on Aug 5, 2014 7:38:30 AM
          Polling SCM changes on Jenkins build slave 1
          Using strategy: Inverse
          [poll] Last Built Revision: Revision 6f4fa39c1e3c588772e9a7c3289926123c064565 (origin/master)
          Fetching changes from the remote Git repositories
          Fetching upstream changes from <GIT REPO>
          Polling for changes in
          ERROR: Failed to record SCM polling for hudson.model.FreeStyleProject@ab80775[JOB NAME]
          java.lang.NullPointerException
          at hudson.plugins.git.util.InverseBuildChooser.getCandidateRevisions(InverseBuildChooser.java:45)
          at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:534)
          at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:456)
          at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
          at hudson.scm.SCM.poll(SCM.java:373)
          at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1605)
          at hudson.model.AbstractProject._poll(AbstractProject.java:1575)
          at hudson.model.AbstractProject.poll(AbstractProject.java:1493)
          at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462)
          at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491)
          at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
          at java.util.concurrent.FutureTask.run(FutureTask.java:262)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          at java.lang.Thread.run(Thread.java:745)

          Markus Heikkilä added a comment - I ran into this bug in Jenkins 1.553 I tried the "workaround": Inverse selection strategy and Force polling with workspace. I get this in the Git polling log when I push change to a non-master branch: Started on Aug 5, 2014 7:38:30 AM Polling SCM changes on Jenkins build slave 1 Using strategy: Inverse [poll] Last Built Revision: Revision 6f4fa39c1e3c588772e9a7c3289926123c064565 (origin/master) Fetching changes from the remote Git repositories Fetching upstream changes from <GIT REPO> Polling for changes in ERROR: Failed to record SCM polling for hudson.model.FreeStyleProject@ab80775 [JOB NAME] java.lang.NullPointerException at hudson.plugins.git.util.InverseBuildChooser.getCandidateRevisions(InverseBuildChooser.java:45) at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:534) at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:456) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) at hudson.scm.SCM.poll(SCM.java:373) at hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1605) at hudson.model.AbstractProject._poll(AbstractProject.java:1575) at hudson.model.AbstractProject.poll(AbstractProject.java:1493) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:462) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:491) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)

          Yan-Fa Li added a comment -

          I've got a very similar issue, but I think it may be related to how git-client tracks what has been built.
          We use github-enterprise and it has a feature called gh-pages. This is a special branch that has only documentation, it's built and force pushed from master from a documentation task.

          The job is configured as build `*/gh-pages` branch with the inverse strategy. Logically I want it to build everything but gh-pages.

          Here's what I'm seeing. Github client checks branch and detects that gh-pages has changed, but can't tell not to build it because it has never been built. It kicks off a build. The builder builds the default branch because it can't tell what branch has changed because the inverse strategy tells it to ignore gh-pages.

          We are using polling to avoid giving jenkins too many privileges on github enterprise. Next time it polls, git client can see gh-pages has changed, but can't find a build with that commit, rinse repeat.

          What would be great is if github client were smart enough to detect that it's running inverse and not build the branch that matches and not kick off a build. My only recourse at this point is to do 1 of 2 things. Stop building branches and only build master; not a great choice. Add a fake build task to gh-pages branch that will allow the branch to be built without error and stop using the inverse strategy.

          Since this involves multiple plugins and strategies I'm not sure who's responsible for fixing it. It's basically a bug expressed because of a particular combination of features and plugins. Any help you can offer is appreciated. Thanks for all the amazing work that goes into Jenkins.

          Yan-Fa Li added a comment - I've got a very similar issue, but I think it may be related to how git-client tracks what has been built. We use github-enterprise and it has a feature called gh-pages. This is a special branch that has only documentation, it's built and force pushed from master from a documentation task. The job is configured as build `*/gh-pages` branch with the inverse strategy. Logically I want it to build everything but gh-pages. Here's what I'm seeing. Github client checks branch and detects that gh-pages has changed, but can't tell not to build it because it has never been built. It kicks off a build. The builder builds the default branch because it can't tell what branch has changed because the inverse strategy tells it to ignore gh-pages. We are using polling to avoid giving jenkins too many privileges on github enterprise. Next time it polls, git client can see gh-pages has changed, but can't find a build with that commit, rinse repeat. What would be great is if github client were smart enough to detect that it's running inverse and not build the branch that matches and not kick off a build. My only recourse at this point is to do 1 of 2 things. Stop building branches and only build master; not a great choice. Add a fake build task to gh-pages branch that will allow the branch to be built without error and stop using the inverse strategy. Since this involves multiple plugins and strategies I'm not sure who's responsible for fixing it. It's basically a bug expressed because of a particular combination of features and plugins. Any help you can offer is appreciated. Thanks for all the amazing work that goes into Jenkins.

          Yan-Fa Li added a comment -

          Running Jenkins in a docker container. v.1642.4 official docker hub image. Plugins Git plugin 2.4.4. Github plugin 1.18.2.

          Yan-Fa Li added a comment - Running Jenkins in a docker container. v.1642.4 official docker hub image. Plugins Git plugin 2.4.4. Github plugin 1.18.2.

          Oleksandr added a comment -

          markewaite workaround with "Force polling using workspace" works for me in 2023 when "Inverse" strategy is in place, otherwise Jenkins erroneously repeats builds forever (we are polling `H/15 * * * *`) with a message:

          > No new revisions were found; the most-recently built branch will be built again.

          The issue duplicates JENKINS-32521

          Oleksandr added a comment - markewaite workaround with " Force polling using workspace" works for me in 2023 when "Inverse" strategy is in place, otherwise Jenkins erroneously repeats builds forever (we are polling `H/15 * * * *`) with a message: > No new revisions were found; the most-recently built branch will be built again. The issue duplicates JENKINS-32521

          Oleksandr added a comment -

          The message

          > No new revisions were found; the most-recently built branch will be built again.

          comes from https://javadoc.jenkins.io/plugin/git/index-all.html

          BuildChooser_BuildingLastRevision() - Static method in class hudson.plugins.git.Messages
          Key BuildChooser_BuildingLastRevision: {{{}No new revisions
          were found; the most-recently built branch will be built again.{}}}.
           

          Oleksandr added a comment - The message > No new revisions were found; the most-recently built branch will be built again. comes from https://javadoc.jenkins.io/plugin/git/index-all.html BuildChooser_BuildingLastRevision() - Static method in class hudson.plugins.git. Messages Key BuildChooser_BuildingLastRevision : {{{}No new revisions were found; the most-recently built branch will be built again.{}}}.  

            Unassigned Unassigned
            jpschewe jpschewe
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: