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

Previous built branch builds again even if removed

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None
    • Platform: Macintosh, OS: All

      After having a build where origin/branchA was built (and failed) and then
      removing origin/branchA from the configuration, on the next build it will try to
      build origin/branchA again.

      Hudson should not try to build branches that are not configured for building.

      Only way I could find to get out of the problem was to delete all builds trying
      to build branchA until I got back to another build.

          [JENKINS-4422] Previous built branch builds again even if removed

          Andrew Bayer added a comment -

          Are you still seeing this? Can you give me a more detailed example so that I can try to reproduce this?

          Andrew Bayer added a comment - Are you still seeing this? Can you give me a more detailed example so that I can try to reproduce this?

          jacobat added a comment -

          I can't recall the details of the issue. Feel free to close the ticket.

          jacobat added a comment - I can't recall the details of the issue. Feel free to close the ticket.

          Lara Fields added a comment - - edited

          I can reproduce this every time on Git Plugin 1.1.12 and it is very simple. The Git BuildChooser is using the Last Built sha from the last build, and is always attempting to checkout that sha when choosing "Build Now". The assumption is that you are trying to re-build the last built thing (as it says in the code comments) That means those changes try to be built, even if you want to always checkout clean (for example by choosing the options to wipe the workspace).

          This continues even when I remove the offending repository from the configuration, because it is pulling the sha from the last build, whether failed or not, and whether I have set it to build clean or not. If I clean things to the point where the reflog no longer contains the offending sha (wiping out the workspace, for example), the git plugin then fails at the beginning because it still tries to check out that sha, which is no longer available.

          My suggestion would be that if the repository containing the "last built thing" is no longer relevant in the configuration, or if it no longer exists in the reflog, the build should act as if it is pulling a brand-new build, rather than rebuilding the last failed build.

          Lara Fields added a comment - - edited I can reproduce this every time on Git Plugin 1.1.12 and it is very simple. The Git BuildChooser is using the Last Built sha from the last build, and is always attempting to checkout that sha when choosing "Build Now". The assumption is that you are trying to re-build the last built thing (as it says in the code comments) That means those changes try to be built, even if you want to always checkout clean (for example by choosing the options to wipe the workspace). This continues even when I remove the offending repository from the configuration, because it is pulling the sha from the last build, whether failed or not, and whether I have set it to build clean or not. If I clean things to the point where the reflog no longer contains the offending sha (wiping out the workspace, for example), the git plugin then fails at the beginning because it still tries to check out that sha, which is no longer available. My suggestion would be that if the repository containing the "last built thing" is no longer relevant in the configuration, or if it no longer exists in the reflog, the build should act as if it is pulling a brand-new build, rather than rebuilding the last failed build.

          Gordon Oliver added a comment -

          I can reproduce a variant of this bug. The problem is that the BuildChooser takes the last build if there are no builds found, and that build may not exist. Specifically, I am using Jenkins to auto-merge branches, and once merged, the original branch is deleted. This leads to a stream of 'success, failure' builds from Jenkins (i.e. if the merge build succeeds, Jenkins always runs a second build, and that second build always fails).

          To reproduce: pre-merge, and a post commit + 'git push :remotebranch'.

          I can provide you with the scripts that duplicate this behavior if you wish. I had to roll my own pre/post scripts to make it do what I wanted...

          My personal preference would be a different strategy, making a build chooser that chooses nothing if it finds no builds, rather than choosing the last build. This means that you won't be able to kick off a manual build if there are no builds that match. This probably means that it can't be the default.

          Gordon Oliver added a comment - I can reproduce a variant of this bug. The problem is that the BuildChooser takes the last build if there are no builds found, and that build may not exist. Specifically, I am using Jenkins to auto-merge branches, and once merged, the original branch is deleted. This leads to a stream of 'success, failure' builds from Jenkins (i.e. if the merge build succeeds, Jenkins always runs a second build, and that second build always fails). To reproduce: pre-merge, and a post commit + 'git push :remotebranch'. I can provide you with the scripts that duplicate this behavior if you wish. I had to roll my own pre/post scripts to make it do what I wanted... My personal preference would be a different strategy, making a build chooser that chooses nothing if it finds no builds, rather than choosing the last build. This means that you won't be able to kick off a manual build if there are no builds that match. This probably means that it can't be the default.

          Mark Waite added a comment - - edited

          I believe this is resolved in git plugin 2.4.0 and git client 1.18.0. The steps I took to verify it include:

          1. Create a bare repository JENKINS-4422.git to which the jenkins job can push
          2. Create a master branch in that bare repo with a README
          3. Create a job monitoring that bare repository
          4. Configure job to build any branch but master (branch to build `:^((?!master).)*$`)
          5. Configure job to poll
          6. Configure job to merge to branch origin/master
          7. Configure job to prune stale remote tracking branches
          8. Configure the git publisher to push the merge result back to origin
          9. Create a branch named "first-attempt" in a working copy with a new commit
          10. Push that branch to the bare repository
          11. Confirm the branch is merged to master and pushed by git publisher
          12. Delete branch named "first-attempt" from the working copy and the bare repo
          13. Checkout branch named "second-attempt" in a working copy based on latest origin/master
          14. Add a commit on "second-attempt" branch, push to bare repo
          15. Confirm the second-attempt branch is merged to master and pushed by git publisher
          16. Configure job to delete branch from bare repo after it is built ( git push origin :$(basename $GIT_BRANCH) )
          17. Confirm source branch is deleted, result is merged to master branch, and job continues operating as expected

          Mark Waite added a comment - - edited I believe this is resolved in git plugin 2.4.0 and git client 1.18.0. The steps I took to verify it include: Create a bare repository JENKINS-4422 .git to which the jenkins job can push Create a master branch in that bare repo with a README Create a job monitoring that bare repository Configure job to build any branch but master (branch to build `:^((?!master).)*$`) Configure job to poll Configure job to merge to branch origin/master Configure job to prune stale remote tracking branches Configure the git publisher to push the merge result back to origin Create a branch named "first-attempt" in a working copy with a new commit Push that branch to the bare repository Confirm the branch is merged to master and pushed by git publisher Delete branch named "first-attempt" from the working copy and the bare repo Checkout branch named "second-attempt" in a working copy based on latest origin/master Add a commit on "second-attempt" branch, push to bare repo Confirm the second-attempt branch is merged to master and pushed by git publisher Configure job to delete branch from bare repo after it is built ( git push origin :$(basename $GIT_BRANCH) ) Confirm source branch is deleted, result is merged to master branch, and job continues operating as expected

            abayer Andrew Bayer
            jacobat jacobat
            Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: