[TerryHowe]

Fixes #212.

What this changes

The floating vX / vX.Y tags are now pushed over SSH with a repository deploy key instead of GITHUB_TOKEN. GitHub doesn't accept GITHUB_TOKEN (the GitHub Actions app) as a ruleset bypass actor, so this is what lets the release-tags ruleset block tag updates by anyone except the release workflows.

• auto-release.yml, update-version.yml: checkout sets ssh-key: ${{ secrets.TAG_DEPLOY_KEY }}. The existing git push --force commands don't change; they now authenticate with the key. Releases are still created with GITHUB_TOKEN.
• check-dist.yml: push is limited to branches. Deploy-key pushes trigger workflows (GITHUB_TOKEN pushes don't), so each floating-tag move would otherwise start a Check dist/ run. branches: ['**'] is used rather than tags-ignore, because a tags-only filter would also stop branch pushes.
• RELEASING.md: documents the deploy key, how to create or rotate it, and how to recover if it's missing.

The release flow is otherwise unchanged: the daily update PR, then merge, then auto-release publishes vX.Y.Z and moves vX / vX.Y.

Deploy key

The release tags deploy key (write access) and the TAG_DEPLOY_KEY secret were created and configured on 2026-10-17. Instructions for rotating the key are in RELEASING.md.

If the secret were ever missing, actions/checkout falls back to GITHUB_TOKEN and the tag push works as it does today. Don't tighten the ruleset until a release has moved the tags with the key.

After merge: tighten the ruleset

Add the update and non_fast_forward rules to release-tags (ID 25296857), with deploy keys as the only bypass actor. Keep deletion, and don't add creation, since maintainers still create vX.Y.0 tags. In the UI: Settings → Rules → Rulesets → release-tags → Bypass list → Deploy keys.

Post-Merge Validation

Scope: oras-project/setup-oras release automation only: the floating-tag push in auto-release.yml and update-version.yml, the Check dist/ push trigger, and the release-tags ruleset. No change to the action's runtime behavior for consumers.

Checks:

• Deploy key exists with write access — gh repo deploy-key list --repo oras-project/setup-oras
• Secret exists — gh secret list --repo oras-project/setup-oras | grep TAG_DEPLOY_KEY
• Manual auto-release run on main succeeds — gh workflow run auto-release.yml --repo oras-project/setup-oras --ref main then gh run list --repo oras-project/setup-oras --workflow auto-release.yml --limit 1
• Ruleset tightened — gh api repos/oras-project/setup-oras/rulesets/25296857 --jq '{rules: [.rules[].type], bypass: .bypass_actors}'
• Next auto-release moves the floating tags — git ls-remote https://github.com/oras-project/setup-oras 'refs/tags/v2*'
• Manual move is rejected — git push origin v2 --force from a maintainer clone fails with a ruleset error
• No Check dist/ runs on tag refs — gh run list --repo oras-project/setup-oras --workflow check-dist.yml --limit 10 --json headBranch --jq '.[].headBranch'

Expected: deploy key release tags with write access; ruleset rules deletion, update, non_fast_forward with deploy-key bypass; after the next release, v2, v2.0 and the new v2.0.N point at the same commit; the auto-release run is green; no Check dist/ runs with headBranch v2 or v2.0.

Rollback: remove the update / non_fast_forward rules from ruleset 25296857, then revert this PR. Without the secret, checkout falls back to GITHUB_TOKEN as before.

[sabre1041]

LGTM

[shizhMSFT]

LGTM