Clear branch protection rules when protected_branches is removed - #121
Merged
Humbedooh merged 1 commit intoAug 13, 2026
Merged
Conversation
Previously, removing the protected_branches key from .asf.yaml left all existing branch protection rules in place; only the explicit "protected_branches: ~" form cleared them. The directive now consults the cached previous configuration, mirroring the rulesets directive: if the key was present in the previously applied .asf.yaml but is now absent, the previously configured branch protection rules are removed. Classic branch protection and rulesets can be active at the same time in GitHub (the most restrictive result applies), so each key needs its own cleanup path. Rulesets already handled removal correctly. Assisted-By: Claude Fable 5 <noreply@anthropic.com>
ppkarwasz
added a commit
to apache/logging-parent
that referenced
this pull request
Aug 16, 2026
No longer needed since apache/infrastructure-asfyaml#121 was merged.
ppkarwasz
added a commit
to apache/logging-parent
that referenced
this pull request
Aug 16, 2026
* Switch to GitHub Rulesets (second attempt) The first attempt (#456) had to be reverted in #471 because a bug in ASFYaml made the resulting rulesets impossible to modify or remove through `.asf.yaml`. We rolled back to the legacy `protected_branches` configuration. apache/infrastructure-asfyaml#93 has now landed and addresses the underlying issues (broken `app_slug` resolution, silent REST API failures, missing `refs/heads/` / `refs/tags/` prefixing), so we can move back to Rulesets. The benefits over `protected_branches` remain: - Tag references can also be protected (see the new `rel/*` ruleset). - A single ruleset can target a glob of refs (e.g. `gha/*`) instead of one branch at a time. - Rules are publicly visible at https://github.com/apache/logging-parent/rules, so we can verify that the effective rules are those configured and third parties can audit the project's protection policy too. * fix: use raw syntax for tags * fix: remove `protected_branches` No longer needed since apache/infrastructure-asfyaml#121 was merged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Removing the
protected_brancheskey from.asf.yamlpreviously left all existing branch protection rules in place; only the explicitprotected_branches: ~form cleared them. Thebranch_protectiondirective now consults the cached previous configuration (previous_yaml), mirroring what therulesetsdirective already does: if the key was present in the previously applied.asf.yamlbut is now absent, the previously configured branch protection rules are removed.Motivation
Classic branch protection rules and rulesets can be active on the same repository at the same time; GitHub evaluates both and applies the most restrictive result. A project migrating from
protected_branchestorulesetswill therefore typically delete theprotected_brancheskey, and would previously end up with stale branch protection rules layered on top of the new rulesets. Therulesetskey already handled removal correctly, so this closes the gap on the branch protection side.Changes
branch_protection.py: the early return now also checksprevious_yaml; when the key was previously configured but is now absent, the directive falls through with an empty branch map and the existing removal loop un-protects all live-protected branches, exactly asprotected_branches: ~does. This is a one-time cleanup, since the configuration cache is rewritten after each run.tests/github_branch_protection.py(new file, there were no branch protection tests before): covers removed-key cleanup, absent-key-with-no-history performing no API calls, the~regression path, noop mode, and a non-dictprevious_yaml.README.md: documents that removing the section has the same effect as setting it to~(as long as thegithub:section still contains other configuration) and notes the coexistence semantics of branch protection and rulesets.Limitations
If the entire
github:block is deleted, the GitHub feature never runs at all, so no cleanup of any kind can happen. This is a pre-existing limitation of the top-level feature dispatch and applies equally to rulesets; it is out of scope here.