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.
On Saturday, June 26, 2021 at 12:41:07 PM UTC-7 Tim Black wrote:
> 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?
>
> On Saturday, June 26, 2021 at 12:07:30 PM UTC-7 Tim Black wrote:
>
>> 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
>> <https://www.jenkins.io/doc/book/managing/system-properties/> 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.
>>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/8f387f98-ba54-4423-9622-2e73354119e2n%40googlegroups.com.
