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

Beginne mit den Migrationszielen und den verknüpften GitHub Repository Rules-Diskussionen und prüfe dann die Repository-Checkliste, einschließlich des abgeschlossenen strong-error-handler-Eintrags. Lege fest, welche bestehenden Regeln für geschützte Branches und Tags zu Rulesets werden müssen und was das Deaktivieren der älteren Regeln und der API bedeutet; abgeschlossen ist die Arbeit mit einem dokumentierten, abgestimmten Migrationsplan oder einer angewendeten Repository-Konfiguration.