-
Bug
-
Resolution: Fixed
-
Major
-
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.
- is related to
-
-
- Closed
-
-
-
- Open
-
-
-
- Open
-
[JENKINS-4422] Previous built branch builds again even if removed
jacobat
created issue -
| Assignee | Original: jbq [ jbq ] | New: Andrew Bayer [ abayer ] |
jacobat
added a comment - I can't recall the details of the issue. Feel free to close the ticket. | Resolution | New: Cannot Reproduce [ 5 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
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. Lara Fields
made changes -
| Resolution | Original: Cannot Reproduce [ 5 ] | |
| Status | Original: Closed [ 6 ] | New: Reopened [ 4 ] |
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. | Status | Original: Reopened [ 4 ] | New: Open [ 1 ] |
Are you still seeing this? Can you give me a more detailed example so that I can try to reproduce this?