Build Enhancements

NOTE: This ticket is a work in progress and currently under discussion by the team. Any subtickets that are suitable for contribution will be marked as ideal-for-contribution.

This ticket is a parent ticket to collect ideas for enhancements and fixes for Spring Security's build and release process

• Increase Timeout for Publishing to Central - addressed in https://github.com/spring-io/spring-security-release-tools/issues/79

---

Improve Pre-Release Automation

There are a number of steps for the release that could be done in advance of the release.
Doing them in advance of the release allows us to check for needed changes with more time, allowing the actual release to go more quickly.

• Automate Creating a Release Signoff Ticket
• Automate Dependabot Port Forwarding
• Automate Drafting a Release Blog Post
• Automate Gradle Wapper Port Forwarding #14546

To be secure, the merge forward support needs to be based off of some aspect that cannot be controlled by those without commit access. One idea is to key off of a label.

---

Improve Release Recoverability

It would be nice if, when a release fails, it was easier to pick up from some checkpoint and re-run things.

• Make Each Build Step Idempotent

-- the publishing step can look to see if the artifact is already there instead of trying to re-release and fail
-- the release notes step can look to see if the release notes are already there and update instead of fail
-- if a step cannot be made idempotent, it should be after a step that is idempotent so that it doesn't happen again, like posting an announcement about the release

• Further Modularize the Build

---

Release Should Run Concurrently with Development

Since Spring Security releases off of main, the team needs to take care to not work on main while the release is happening.
This can create a bottleneck when some part of the release is unexpectedly protracted.

• Release main off of a release branch
• Release maintenance branches off of a release branch

---

Align Commercial and OSS GHA Configuration

There are a number of places where Commercial and OSS configuration are currently irreconcilable. We should be able to rework them to minimize any manual settings to make something commercial.

---

Simplify Moving a Generation from One Stage to Another

Spring Security OSS has three generation types; major, minor, maintenance, and commercial.
For each of these, code and configuration undergo a number of steps to move from one to the other.

It would be nice if there were automation that created a PR for each of these, based on the creation of a task. Contributors could push to that PR anything that is not yet automated.

• Automate Moving main to Maintenance Development Mode
• Automate Moving main to Minor Development Mode
• Automate Moving main to Major Development Mode

---

Simplify Moving a Generation from OSS to Commercial

Here are the steps for moving a generation from OSS to Commercial:

1. Change the origin to spring-security-commercial and push
2. Change the copyright headers
3. Change references to "spring-security" to "spring-security-commercial"
4. Push those changes

It'd be nice if there were automation that, once a branch was pushed, it changed copyright headers and CI references for us and published them as a PR to spring-security-commercial.

---

Automation Should Check for Package Tangles

We should engage a tool that will fail the build if it doesn't meet architectural standards, like looking for package tangles

---

• #15656
• #16764