Release is blocked if branch protection is enabled

I want to enforce each PR/commit is reviewed before merging. So I enabled Github branch protection rule. However, I find projen release workflow will push a commit automatically which is against the branch protection rule.

Below is the workflow: https://github.com/aws-samples/cdk-keycloak/runs/1976482226?check_suite_focus=true

git push origin $BRANCH
  shell: sh -e {0}
  env:
    CI: true
    BRANCH: refs/heads/main
remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: At least 1 approving review is required by reviewers with write access.        
To https://github.com/aws-samples/cdk-keycloak
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/aws-samples/cdk-keycloak'
Error: Process completed with exit code 1.

[eladb]

@Chriscbr Good points.

Is it possible to have the workflow automatically create a pull request instead of pushing directly, and then auto-approve said PR (maybe with an automerge label, or by calling a REST API endpoint)?

This will introduce a race condition on “main”. If a commit is merge between the time the PR was created and the time it’s merged, the version will include this change but it will not be accounted for in the changelog. This is probably not an issue for small projects but when traffic on “main” grows, it can be an issue.

Would creating a separate “release” branch (and applying different release protection rules) solve any of these issues?

This is possible but slightly cumbersome. This is the model we use in the CDK. It requires back-merging from the release branch after every release, which is more automation, and if there is branch protection, you’ll need a dedicated auto-approve workflow…

Is it possible to set the release flow to be run with a custom bot user with limited admin privileges (i.e. no repo deletion) to bypass the branch protection rules? This would require the branch protection rules to be set to not apply to administrators.

I rather not require every project to install another secret.

---

The proposed model basically manages version information only through git tags which is actually a pretty common model. E.g Go modules use git tags to indicate module version.

It’s also a more robust model than what we have today because there’s a single source of truth (today we need maintain both tags and a version file in sync).

It will also allow us to cleanly decouple “main” builds and publishing the release. We can say that the main build creates a GitHub release+tag at the end of the build and uploads the build artifact in there.

The publishing workflow(a) are triggered when a new release/tag is created. They download the artifact and publish to the respective package manager.

[eladb]

Indeed!