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

nextBuildNumber not updated when reload configuration

      Steps to Reproduce:
      1) Create a Freestyle Job. Add a "sleep 120" command to the job.
      2) Execute the Freestyle Job twice. One instance will execute, the other instance will be in the queue.
      3) While first instance is executing issue "Reload From Disk Command" either via Browser, CLI, or Manage Jenkins Menu
      4) Wait till both instances complete execution.
      5) Execute the Freestyle Job once more

      At this point you will receive a Dead Thread, with the following:
      java.lang.IllegalStateException: /var/lib/jenkins/jobs/Long Run Job/builds/2 already existed; will not overwrite with Long Run Job #2
      at hudson.model.RunMap.put(RunMap.java:188)
      at jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:176)
      at hudson.model.AbstractProject.newBuild(AbstractProject.java:1019)
      at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1210)
      at hudson.model.AbstractProject.createExecutable(AbstractProject.java:145)
      at hudson.model.Executor$1.call(Executor.java:364)
      at hudson.model.Executor$1.call(Executor.java:346)
      at hudson.model.Queue._withLock(Queue.java:1405)
      at hudson.model.Queue.withLock(Queue.java:1270)
      at hudson.model.Executor.run(Executor.java:346)

      Three instances of the job have been tried to run. The first instance completed successfully, however the second instance, the one that was pending in the queue during the Reload Configuration From Disk, succeeded, however the nextBuildNumber will not be incremented to 3, but will remain 2.

      When the third instance the one that fails immediately with the above exception, it is trying to use 2 instead of because the nextBuildNumber says 2 is the correct value.

      Also if at the time of the "Reload Configuration from Disk" is executed, there are X number of copies of the same job in the Queue, pending execution, all of these will properly execute afterward, however, that job will fail X number times after those have completed.

          [JENKINS-33794] nextBuildNumber not updated when reload configuration

          Jesse Glick added a comment -

          Duplicate of something already filed.

          Jesse Glick added a comment - Duplicate of something already filed.

          Jeff Miller added a comment -

          FYI - this is reproduced with a clean 1.642.3 Install on Red Hat with NO additional plugins, and No changes in the plugins.

          Jeff Miller added a comment - FYI - this is reproduced with a clean 1.642.3 Install on Red Hat with NO additional plugins, and No changes in the plugins.

          Jeff Miller added a comment -

          Further investigation it appears, that when a job has pending builds, and a reload is done the hudson.model.Run object in the pending build queue, points back to the hudson.model.Job object. When a reload is done, a new hudson.model.Job is created and that is used for new builds. This results in a build number being used that is a duplicate of the the builds that were in the pending build queue when the reload was done.

          The hudson.model.Job needs to have a reload, where it will update correctly including the nextBuildNumber, to provide the hudson.model.Run objects in the pending build queue a valid object to point back to.

          Jeff Miller added a comment - Further investigation it appears, that when a job has pending builds, and a reload is done the hudson.model.Run object in the pending build queue, points back to the hudson.model.Job object. When a reload is done, a new hudson.model.Job is created and that is used for new builds. This results in a build number being used that is a duplicate of the the builds that were in the pending build queue when the reload was done. The hudson.model.Job needs to have a reload, where it will update correctly including the nextBuildNumber, to provide the hudson.model.Run objects in the pending build queue a valid object to point back to.

          Jesse Glick added a comment - - edited

          jeff_a_miller yes that appears to be the correct analysis, that a Queue.Item.task refers to a stale Job.

          Jesse Glick added a comment - - edited jeff_a_miller yes that appears to be the correct analysis, that a Queue.Item.task refers to a stale Job .

            Unassigned Unassigned
            jeff_a_miller Jeff Miller
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: