Migrate Github Protected Branch/Tag Rules rules to Github Repository Rules rulesets

Github Repository Rules, which has reached general-availability, is an evolution of Github Protected Branch/Tag. This issue is to track:

1. Converting existing Github Protected Branch/Tag rules to Github Repository Rules rulesets
2. Disabling the older branch protection rules and api

Further discussions

With this new solution, we should also consider the new potentials for enforcing repository security.

Org-wide enforcement

Enforcing an org-wide Github Repository Rules ruleset is only available for Github Enterprise users. However, we can consider creating a Github Action workflow in https://github.com/loopbackio/cicd to periodically poll and enforce. This would be of similar concept to our potential adoption of Peribolos (https://github.com/loopbackio/cicd/issues/26).

Although the adoption of the OpenSSF Scorecard Action (https://github.com/loopbackio/security/issues/25) would allow us to detect non-compliance, it is not granular enough, does not have auditable self-remediation capabilities, and does not provide a single pane of glass.

Restricting bots' branches

TLDR: This is not fully possible.

Bots such as Renovate require push-rights to our Github repositories. However, this opens us up to third-party vendor risk where misused bot credentials can cause unwanted, destructive commit and tag modification to our repositories.

This is already partially-alleviated with the older Github Protected Branch/Tag feature, where we're able to mandate the creation of a pull request and restrict who can push new Git tags. However, we are not able to enforce this for the non-publishing (i.e. work-in-progress) branches which are created and deleted day-to-day.

Although Github Repository Rules allows layering and creation of bypass lists, it does not have an "apply to select bots/people only". This means that, even with a bypass list with non-bot members, we would still need to "bypass " the rules (i.e. "override" the rule) via the pull request page every time we want to merge. This is not ideal.

Repositories

• loopbackio/strong-error-handler

Start with the migration goals and linked GitHub Repository Rules discussions, then review the repository checklist, including the completed strong-error-handler entry. Define which existing protected branch and tag rules must become rulesets and what disabling the older rules and API means; completion is a documented, agreed migration plan or applied repository configuration.