Repository navigation
[JENKINS-4930] Next build number plugin should allow decrementing #19180
Description
Firstly, it doesn't look like there's a subcomponent defined for the "Next Build
Number" plugin, so I've just assigned this to "plugin".
There is a case when a user has launched a build (either manually or scheduled)
and it needs to be deleted and the same (or similar) build run again. This
happens when there is some kind of network or power outage unrelated to the
source code.
In this case, I'm still having to edit the "nextBuildNumber" files on the disk
and reload the configuration from disk. This is quite annoying because it
doesn't work well when builds are running, so you must have some downtime.
To keep a long story short, it would be nice to be able to decrement the build
number using the "Next Build Number" plugin as this plugin is awesome and has
saved me a lot of time!!!
Originally reported by jonny5, imported from: Next build number plugin should allow decrementing
- assignee:
kohsuke
- status: Closed
- priority: Blocker
- component(s): core
- resolution: Fixed
- resolved: 2010-05-31T09:19:29+00:00
- votes: 0
- watchers: 0
- imported: 2025-11-24
Raw content of original issue
Firstly, it doesn't look like there's a subcomponent defined for the "Next Build Number" plugin, so I've just assigned this to "plugin".
There is a case when a user has launched a build (either manually or scheduled) and it needs to be deleted and the same (or similar) build run again. This happens when there is some kind of network or power outage unrelated to the source code.
In this case, I'm still having to edit the "nextBuildNumber" files on the disk and reload the configuration from disk. This is quite annoying because it doesn't work well when builds are running, so you must have some downtime.
To keep a long story short, it would be nice to be able to decrement the build number using the "Next Build Number" plugin as this plugin is awesome and has saved me a lot of time!!!
- environment:
Platform: All, OS: All
Activity
jenkins-infra-bot commentedon Dec 1, 2009
Raw content of original comment:
Moving to new next-build-number component.
jenkins-infra-bot commentedon Feb 9, 2010
hmonteiro:
Raw content of original comment:
Just to let know that, although the plugin's name is "Next build number", I wasn't expceting to allow only to jump a build number forward, only.
I installed it because I thought it would allow me to specify the next build number, not as "next" (increasing) but has the number I wanted, either increasing or decreasing. I was also expecting to even be able to specify the same number as an existing build if, and only if, the build wasn't successfull or aborted.
That was what I was wondering this plugin did.
jenkins-infra-bot commentedon Feb 9, 2010
hmonteiro:
Raw content of original comment:
It would be nice that we could specify a past "next build number" only until the last successful build number, that is, allow only to replace failed or aborted past builds.
example:
Builds:
#8 - Failed
#7 - Aborted
#6 - Failed
#5 - Aborted
#4 - Success
#3 - Success
#2 - Aborted
#1 - Success
"Next build number" should allow that the smaller number to be specified be #5, because #4 was already successful (the last successful build found).
So, by specifying #5, builds #6, #7, #8 would be automatically deleted, and the next build would be #5.
This behaviour would be of tremendous help, since there are alot of aborted or failed builds when a new job is created and fine tuned until it starts working as it is supposed to.
So instead of deleting failed/aborted builds on disk, and reloading hudson's configuration this plugin could clean-up unecessary failed/aborted job's from build's history.
Reloading hudson configurations in large hudson deployments it's basically impossible to do so, because of constant running builds that can't be stopped (some can take several hours to build).
ULTIMATE BENEFIT of this feature: decreasing hudson's downtime, by removing the need of constantly reloading hudson's configuration in some situations.
jenkins-infra-bot commentedon Mar 11, 2010
jonny5:
Raw content of original comment:
I had a look at the code and it looks like the next build number plugin is doing everything correctly. This looks like an issue with Hudson:
/** * Programatically updates the next build number. * ** Much of Hudson assumes that the build number is unique and monotonic, so * this method can only accept a new value that's bigger than * {@link #getNextBuildNumber()} returns. Otherwise it'll be no-op. * * @since 1.199 (before that, this method was package private.) */ public synchronized void updateNextBuildNumber(int next) throws IOException { if (next > nextBuildNumber) { this.nextBuildNumber = next; saveNextBuildNumber(); } }
I'm just wondering if this test for (next > nextBuildNumber) is really necessary...the test isn't done when reading from a file. It should really be checking if there are any builds between next and nextBuildNumber (as it is possible to delete builds).
jenkins-infra-bot commentedon Mar 11, 2010
jonny5:
Raw content of original comment:
I fully tested this version and it resolves this bug:
/** * Programatically updates the next build number. * ** Much of Hudson assumes that the build number is unique and monotonic, so * this method can only accept a new value that's bigger than * {@link #getLastBuild()} returns. Otherwise it'll be no-op. * * @since 1.199 (before that, this method was package private.) */ public synchronized void updateNextBuildNumber(int next) throws IOException { RunT lastBuild = getLastBuild(); if (next > lastBuild.getNumber()) { this.nextBuildNumber = next; saveNextBuildNumber(); } }
I don't have permission to submit, is someone able to do it for me?
jenkins-infra-bot commentedon Mar 18, 2010
jonny5:
Raw content of original comment:
Here is the diff file for Job.java to make it easier for someone to apply the patch
jenkins-infra-bot commentedon Mar 19, 2010
mdonohue:
Raw content of original comment:
I don't think this is a patch that should go in stealthily. If you want this change, I'd suggest joining the dev list, and seeing what folks think of the patch.
The invariant that build numbers are always increasing has been there for a long time, so I suspect the consequences of removing this check would be non-trivial.
jenkins-infra-bot commentedon Mar 19, 2010
jonny5:
Raw content of original comment:
I don't think this deviates from the build numbers always increasing as it will only allow decrementing if builds have been deleted.
Anyway, this can already be done by setting the number in a file and reloading the configuration from disk. This patch just helps with system downtime as you don't need to wait for all slaves to be idle to fix one job's build number.
jenkins-infra-bot commentedon May 31, 2010
Raw content of original comment:
Code changed in hudson
User: : kohsuke
Path:
trunk/hudson/main/core/src/main/java/hudson/model/Job.java
trunk/www/changelog.html
http://jenkins-ci.org/commit/31572
Log:
[FIXED JENKINS-4930] Allow the build number to be set so long as it's still bigger than the last build.