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

Next build number plugin should allow decrementing

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • core
    • None
    • Platform: All, OS: All

      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!!!

          [JENKINS-4930] Next build number plugin should allow decrementing

          Andrew Bayer added a comment -

          Moving to new next-build-number component.

          Andrew Bayer added a comment - Moving to new next-build-number component.

          hmonteiro added a 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.

          hmonteiro added a 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.

          hmonteiro added a comment - - edited

          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.

          hmonteiro added a comment - - edited 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.

          jonny5 added a 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.
               * 
               * <p>
               * 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).

          jonny5 added a 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: https://svn.dev.java.net/svn/hudson/trunk/hudson/main/core/src/main/java/hudson/model/Job.java /** * Programatically updates the next build number. * * <p> * 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).

          jonny5 added a comment -

          I fully tested this version and it resolves this bug:

              /**
               * Programatically updates the next build number.
               * 
               * <p>
               * 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?

          jonny5 added a comment - I fully tested this version and it resolves this bug: https://svn.dev.java.net/svn/hudson/trunk/hudson/main/core/src/main/java/hudson/model/Job.java /** * Programatically updates the next build number. * * <p> * 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?

          jonny5 added a comment -

          Here is the diff file for Job.java to make it easier for someone to apply the patch

          jonny5 added a comment - Here is the diff file for Job.java to make it easier for someone to apply the patch

          mdonohue added a 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.

          mdonohue added a 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.

          jonny5 added a 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.

          jonny5 added a 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.

          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.

          SCM/JIRA link daemon added a 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.

            kohsuke Kohsuke Kawaguchi
            jonny5 jonny5
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: