Skip to content

Add restrict_update convenience key to prevent tags from being moved - #120

Open
ppkarwasz wants to merge 1 commit into
apache:mainfrom
ppkarwasz:feat/tag-ruleset-restrict-update
Open

Add restrict_update convenience key to prevent tags from being moved#120
ppkarwasz wants to merge 1 commit into
apache:mainfrom
ppkarwasz:feat/tag-ruleset-restrict-update

Conversation

@ppkarwasz

@ppkarwasz ppkarwasz commented Aug 13, 2026

Copy link
Copy Markdown
Member

Summary

Tag rulesets written in the convenience syntax now emit GitHub's update rule by default, via a new restrict_update convenience key. This prevents existing tags from being moved to a different commit by anyone without bypass permission, matching the semantics of the deprecated protected_tags setting.

Defaults differ by target:

  • type: branch: restrict_deletion and restrict_force_push remain enabled by default (unchanged); restrict_update defaults to false, since an update rule on branches would block all pushes for non-bypass actors.
  • type: tag: additionally enables restrict_update by default.

Both targets can override the defaults explicitly (restrict_update: true on branches, restrict_update: false on tags).

Motivation

As part of apache/logging-parent#477, the Logging Services project is migrating its branch and tag protection to rulesets. Without an update rule, a convenience-syntax tag ruleset protects tags from deletion and force-pushes, but not from being moved, so tag rules had to be written in the raw payload syntax. With this change, tag rules can be expressed entirely in the convenience format.

Changes

  • restrict_update added to the convenience key set (recognized in convenience entries, rejected when mixed into raw payloads).
  • _is_safety_rule_enabled() gained a target-aware default, used to emit {"type": "update"}.
  • Tests: minimal tag entries now assert exactly ["deletion", "non_fast_forward", "update"], plus coverage for explicit true/false on both targets, invalid types, and mixed raw/convenience rejection.
  • README: documented the per-target default and noted that tag rulesets now match the old protected_tags semantics out of the box.

Raw payload entries are unaffected.

Fixes #96

Tag rulesets written in convenience syntax now emit GitHub's "update"
rule by default, preventing existing tags from being moved to a
different commit by anyone without bypass permission. This matches the
semantics of the deprecated protected_tags setting and removes the need
to fall back to the raw payload syntax for tag protection.

Branch rulesets keep their previous defaults (restrict_deletion and
restrict_force_push only), since an update rule on branches would block
all pushes for non-bypass actors. Branches can still opt in with
"restrict_update: true" and tags can opt out with
"restrict_update: false".

Assisted-By: Claude Fable 5 <noreply@anthropic.com>
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

Successfully merging this pull request may close these issues.

Add support for restrict_update to Rulesets convenience rules

1 participant