Open CarlAmko opened 1 year ago
Just to make sure I understand the goal here:
0.3.0-SNAPSHOT
or such. We probably want that version to be semver.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".1.0.0-SNAPSHOT
or such if there's sufficiently semver-interesting changesThat 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?
@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.
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:
main
as a protected branch