Job.BuildNumberAssigner

[jglick]

In CloudBees CI in high availability mode, the default behavior of Job.assignBuildNumber (updating a counter in memory, and writing it to disk) is not suitable for rapid build triggers of a single job; an external counter is needed at least transiently (the nextBuildNumber file is fine for a durable count). This beta extension point allows a plugin to swap in an alternate strategy for maintaining the next build number.

The BuildNumberAssignment return type is a bit awkward but I could not think of a better API. Job.saveNextBuildNumber is protected, so not usable from alternate implementations, and I did not want to make it public solely for the benefit of a beta API. (Introducing a public alias also seemed weird.) The method introduced in #9019 does not save, whereas the older updateNextBuildNumber method remains undesirable here because of its call to getLastBuild. Automatically calling saveNextBuildNumber from assignBuildNumber would change sychronization behavior for the default implementation, and making assignBuildNumber be synchronized would be undesirable for the CloudBees CI implementation. Reworked, I hope more clearly.

This PR makes #9778 not strictly necessary but I think it remains appropriate anyway.

Testing done

Effectiveness confirmed by a functional test in CloudBees CI.

Proposed changelog entries

• N/A

Before the changes are marked as ready-for-merge:

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[Vlatombe]

LGTM

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[MarkEWaite]

Plugin BOM reports a test failure in the jacoco plugin when testing weekly with Jenkins 2.484.

jenkinsci/bom#3912 (comment)