Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guide: using beachball without persistent admin access #1008

Open
ecraig12345 opened this issue Nov 20, 2024 · 0 comments
Open

Guide: using beachball without persistent admin access #1008

ecraig12345 opened this issue Nov 20, 2024 · 0 comments

Comments

@ecraig12345
Copy link
Member

ecraig12345 commented Nov 20, 2024

Problem

In repos with branch policies preventing users from pushing directly to main, the most common way to let beachball push bumps and changelogs back has been to use a repo admin's PAT to bypass policies. With enterprise policies that prevent giving users persistent admin access to repos, it's necessary to find a different approach.

Workaround

The workaround is to migrate from branch protection rules to rulesets (if not already done) and give a group or role bypass permissions.

If you're not already, you should also be using a fine-grained PAT with write permissions to ONLY the current repo for beachball publishing.

(In my testing with traditional branch protection rules and a fine-grained PAT, even if the PAT owner was listed under "Restrict who can push to matching branches," pushing failed due to missing status checks. But the bypass permission for a ruleset worked to bypass all requirements.)

Bypass configuration

Unfortunately it's not possible to give an individual bypass permissions for a ruleset (only groups or roles). So you can either:

  • Create a group (as small as possible) including the relevant user, and allow the group to bypass
  • Allow the "Maintain" role to bypass (if it's restricted to a small set of users). This also facilitates similar to the previous behavior where admins could force merge PRs.

Ruleset options

Ruleset options should match your previous branch protection options, but generally:

  • Bypass list: as above
  • Target branches: default branch (+ any others)
  • Branch rules: as matching your old rule, but generally...
    • Restrict creations
    • Do NOT "Restrict updates" as this will prevent anyone from merging PRs (even if they have write access and status checks have passed) unless they're on the bypass list!
    • Restrict deletions
    • Require a pull request before merging (X required approvers, require code owners)
    • Require status checks to pass before merging (as before; you may have to manually enter build names and change the source to "github actions")
    • Block force pushes

Now delete your old branch protection rule, and change permissions for former admin users/groups to "maintain."

@ecraig12345 ecraig12345 pinned this issue Nov 20, 2024
@ecraig12345 ecraig12345 changed the title Guidance for JIT access and limited PAT lifetimes Guidance: using beachball without persistent admin access Dec 4, 2024
@ecraig12345 ecraig12345 changed the title Guidance: using beachball without persistent admin access Guide: using beachball without persistent admin access Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant