Design and implement a better release workflow

[CarlAmko]

We are currently unable to bypass our main branch protection, which prevents our Release CI from pushing version number updates to our POMs. This requires some undesirable workarounds in order to perform a release via CI.

This seems to be a highly requested and discussed feature that has been lacking support from GitHub Actions for a while now.

Goals:

• Allow us to continue to use CI to perform releases
• Allow us to keep main as a protected branch

[euank]

Just to make sure I understand the goal here:

1. On main, we have a version like 0.3.0-SNAPSHOT or such. We probably want that version to be semver.
2. During release, we want to have one commit with 0.3.0 which is the release commit, and then immediately have a 0.3.1-SNAPSHOT commit after that which is "start next development release".
3. PRs, updates, etc, may update the above to something like 1.0.0-SNAPSHOT or such if there's sufficiently semver-interesting changes
4. Repeat 1

That all makes sense to me, but I just want to kinda confirm that's the intended flow here.

The naive idea I'd have for this would be to have branch protection on, but have an exception for the ngrok-ci bot, allowing it to push during the release flow.

I guess the reason we might not want to do that is because we want to use github actions? Is that the thing that makes that an undesirable solution?

[CarlAmko]

@euank

That all makes sense to me, but I just want to kinda confirm that's the intended flow here.

Yeah, you pretty much got the process down. We use the Maven release plugin which coordinates and executes these steps.

I'd say we're loosely following semver in general. We'll likely have guidelines more refined when ngrok-java gets to Beta.

The naive idea I'd have for this would be to have branch protection on, but have an exception for the ngrok-ci bot, allowing it to push during the release flow.

Yeah, I think you're tracking correctly. We have branch protection on, and we attempted to allow for an exception for CI to bypass said restrictions. However, as I cited above, there's not a great built-in bypass for GitHub Actions specifically.

The current flow involves manually disabling branch protection to allow for GitHub Actions runners to successfully make a release commits + tag.