auto updating job's nextBuildNumber after restoring build history from another controller?

[Tim Black]

Is there a way to make Jenkins automatically detect the latest build from the history and automatically update the nextBuildNumber file? 

We are using the "jenkins.model.Jenkins.buildsDir" system property to separate jobs/ from builds/. When provisioning a new staging environment for our jenkins controller, we restore the build history from the production controller by rsyncing their buildsDirs. 

On restart of the fresh new staging controller, the GUI for each job page correctly shows the build history, but the nextBuildNumber files are not updated correctly, and remain in their initial state. Because these indicate the next build number to be 1, when I click Build, nothing happens, and an error is logged in /var/log/jenkins/jenkins.log indicating that build number 1 already exists and it cannot overwrite. The nextBuildNumber file gets incremented, and next time it complains about build 2 existing, and so forth. So, presumably this will happen until next build number gets up to the 1 past the most recent build in the history that was rsynced over from production.

Are we going to have to script a solution, or is there a way to make Jenkins automatically detect the latest build from the history and automatically update the nextBuildNumber file?

We're using Jenkins CasC to manage all jenkins configuration, and the above system tries to implement a solution for backing up and restoring build history, to provide build history continuity across promotions of jenkins clusters across dev/test/staging/prod environments.

[Tim Black]

Started down the path of inventing a solution with groovy, following the below model for a single branch job:

def jobName = "MyProject/develop"

def job = Jenkins.instance.getItemByFullName(jobName)

lastBuild = job.getLastBuild()

println("last Build number is " + lastBuild.getNumber())

println("job.nextBuildNumber is currently " + job.nextBuildNumber)

job.updateNextBuildNumber(lastBuild.getNumber())

println("job.nextBuildNumber was set to " + job.nextBuildNumber)

This prints out the right thing but subsequently I have to click build twice to actually trigger the next (correct) build number.

Anyone know of a better way to implement this?

[Tim Black]

A better way to reset all nextBuildNumber files after restoring build history is to delete all of them and restart Jenkins. Jenkins seems to recreate the files for every job based on the most recent build detected in the history.