allowlist-check: warn about upcoming action expirations (closes #987)#1038
Merged
Conversation
Approved action versions are given an expires_at grace period (typically ~3 months) when a newer version lands, and are eventually removed from the allowlist -- at which point workflows still pinning the old SHA start failing the allowlist check. Projects previously had no advance notice. allowlist-check now also fetches actions.yml (which carries the expires_at metadata that approved_patterns.yml lacks) and emits a non-failing ::warning:: for any allowlisted pin in the caller's workflows that expires within 'expiry-warning-days' (new input, default 30). Warnings never change the exit code; they surface in the job log / PR annotations so projects can bump the pin before it breaks. - check_asf_allowlist.py: load_expiry_map() + upcoming_expiry_warnings() pure helpers, emit_expiry_warnings(), and an optional second CLI arg for actions.yml (1-arg invocation stays backward-compatible). - action.yml: fetch actions.yml (best-effort) and pass EXPIRY_WARNING_DAYS. - Tests for the new logic (48 pass) and README documentation. Generated-by: Claude Opus 4.8 (1M context) via Claude Code
raboof
approved these changes
Jul 14, 2026
Member
|
This should ideally rarely happen since dependabot (or equivalent) should be creating update PRs and these should be reviewed and merged, but I can see how it might be helpful to have an additional signal that such an update is still pending. |
Contributor
|
Thanks a lot! |
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
3 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.
Closes #987.
Problem
Approved action versions don't live forever: when a newer version is approved, an older pinned SHA is given an
expires_atgrace period (typically ~3 months) and is eventually removed from the allowlist. Once removed, any workflow still pinning that SHA starts failing the allowlist check -- with no prior warning.What this adds
allowlist-checknow also fetchesactions.yml(which carries theexpires_atmetadata thatapproved_patterns.ymldoesn't) and emits a non-failing::warning::for any allowlisted pin in the caller's workflows that expires withinexpiry-warning-days(new input, default 30):Warnings never change the exit code -- they surface in the job log and PR annotations so projects get advance notice.
Details
check_asf_allowlist.py:load_expiry_map()+upcoming_expiry_warnings()(pure, unit-tested) helpers,emit_expiry_warnings(), and an optional second CLI arg foractions.yml. The 1-arg invocation stays fully backward-compatible (no warnings, unchanged behavior).action.yml: fetchesactions.ymlbest-effort (if it can't be fetched, the check still runs, just without expiry warnings) and passes the newEXPIRY_WARNING_DAYS.Set to
0to warn only once a pin has actually expired, or raise it (e.g."60") for earlier notice.Note
I implemented this from the issue title/intent -- GitHub's API was unreachable from my environment when I built it, so I couldn't read the issue body verbatim. If #987 specified a different threshold default, warn-vs-fail behavior, or data source, say the word and I'll adjust.
🤖 Generated with Claude Code