You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow-list the release candidate's RC and GA tags for runner groups
Release binaries are built from tags, not branches: pushing v2.14.0-rc1
runs the build workflows at refs/tags/v2.14.0-rc1. GitHub matches
selected_workflows entries on the exact ref, so the @refs/heads/release/2.14
entries this script already emits do not authorize those runs, and the tag
had to be added to the groups by hand for 2.14.0-rc1.
Emit the candidate version's tag refs alongside the branch refs. Only the
GA tag and the newest v<version>-rc<n> are pinned; each RC supersedes the
last, and pinning every one would grow both the allow-list and the per-ref
discovery cost by a workflow set per tag (2.13 reached rc15). A newer RC
evicting an older one is fine - the allow-list is checked when a job starts,
so in-flight builds are unaffected.
Tags come from git/matching-refs, which returns the refs under the prefix in
one request rather than paging pytorch/pytorch's entire tag history. The
prefix is not anchored (v2.1 also matches v2.1.0), so names are still
filtered against the exact tag pattern.
0 commit comments