Verify GH action tag/SHA combinations by snazy · Pull Request #356 · apache/infrastructure-actions

snazy · 2025-11-07T15:49:54Z

This change introduces a new function verify_actions to validate the contents against GitHub.

TL;DR
The function verifies that the SHAs specified in actions.yml exist in the GH repo. Also ensures that the SHA exists on the Git tag, if the tag attribute is specified. The rest of the function is a lot of output and error(failure) and warning collection.

Although it issues quite a few GH API requests, the rate limiter should not kick in (with an authenticated GH token, GH workflows have a limit of 15k requests). I opted to rely on the HTTP/1.1 urllib.request stuff, which has no connection-reuse. The alternative would have been to add a dependency.

The algorithm roughly works like this, for each action specified in actions.yml:

Issue a warning and stop, if the name is like OWNER/* ("wildcard" repository). Can't verify Git SHAs in this case.
Issue a warning and stop, if the name is like docker:* (not implemented)
Issue an error and stop, if the name doesn't start with an OWNER/REPO pattern.
Each expired entry is just skipped
If there is a wildcard reference and a SHA reference, issue an error.

Then, for each reference for an action:

If no tag is specified, let GH resolve the commit SHA. Emit a warning to add the value of the tag attribute, if the SHA can be resolved. Otherwise, emit an error.
If tag is specified:
- Add the SHA to the set of requested-shas-by-tag
- Call GH's "matching-refs" endpoint for the 'tag' value
  - Emit en error, if the object type is not a tag or commit.
  - Also resolve 'tag' object types to 'commit' object types.
  - Add each returned SHA to the set of valid-shas-by-tag.
For each "requested tag" verify that the sets of valid and requested shas intersect. If not, emit an error.

Fixes #110

snazy · 2025-11-07T15:51:24Z

This is in a very early stage and meant to just gather feedback and opinions about the approach.

snazy · 2025-11-17T20:14:57Z

@raboof do you think it's worth tackling this one?

raboof · 2025-11-18T08:55:17Z

This looks helpful to me. Does it actually share code with gateway.py or could it be a separate file?

snazy · 2025-11-18T08:57:30Z

This looks helpful to me. Does it actually share code with gateway.py or could it be a separate file?

It does use the load_actions and a data class. But nothing that presents moving the code to a separate .py file.

snazy · 2025-12-21T14:45:23Z

Made some progress on this one.

Moved the code to a separate source file and added it to the update_actions workflow.
The output (github summary) would yield five failures.
One is tackled via #426 (my bad, included in this PR as well for now).

The four remaining ones are because the the ScaCap organization has an IP allow list enabled, which prevents GH hosted runners to perform GH API requests against their org, which prevents the verification code to verify the SHAs and tags. The checks work fine for the ScaCap org from my machine.
I have added a new boolean flag ignore_gh_api_errors for action-references to let the verification code ignore GH API failures. Setting this flag to true means that GH API errors are ignored, but the checks still happen and verification errors are still emitted, just not as failures but as warnings.
Updated the actions.yml with that flag for the scacap/action-surefire-report action.

The warnings are:

Two references to Docker images (not verified)
Two wildcard repository references
- golangci/*
- rustsec/*
Two SHAs without a tag name
- browser-actions/setup-geckodriver
- damccorm/tag-ur-it
Two wildcard SHA and specific SHA references for the same action
- sbt/setup-sbt
- gradle/wrapper-validation-action

raboof · 2026-02-12T09:18:14Z

gateway/action_tags.py

+    # Unauthorized GH API requests are quite rate-limited.
+    # Tip: add an extra space before 'export' to prevent adding the line to the shell history.
+    #    export GH_TOKEN=$(gh auth token)
+    gh_token = os.environ['GH_TOKEN']


isn't GITHUB_TOKEN more common? (and perhaps even already set?)

IIRC secrets (like the GITHUB_TOKEN) need to be passed explicitly from workflows.
I've used then name GH_TOKEN as it's used for example here or here.

Makes sense - OK to keep it then (though perhaps we should standardize on one)

raboof · 2026-02-12T09:19:58Z

.github/workflows/update_actions.yml

          g.update_patterns("approved_patterns.yml", "actions.yml")

+          import action_tags as at
+          result = at.verify_actions("actions.yml")


can we move this to a job that only has contents: read permissions?

raboof

This seems like a helpful check. I'm not sure it should be executed as part of the Handle Dependabot update workflow, perhaps it should be in its own periodically-scheduled workflow? we'd expect dependabot to specify the 'right' values, but they might change over time.

snazy · 2026-02-12T10:39:38Z

Moving to draft, as this depends on #478, #479 and #480 now

incorrectly introduced in https://github.com/apache/infrastructure-actions/pull/419/changes Also adding 0.18.0 as used in https://github.com/apache/skywalking-data-collect-protocol/blob/master/.github/workflows/ci.yaml

follow-up on apache#363, apparently missed some

Remove 'expires_at' if there is also 'keep', since 'keep' currently takes precendence. We'll want to remove the 'keep' entries for most of these cases eventually, but let's do that gradually to reduce impact. See also apache#252

Add the "current" Git commit ID for the moving tag.

Update the moving tag `v5` with the current SHA.

This change introduces a new function `verify_actions` to validate the contents against GitHub. TL;DR The function verifies that the SHAs specified in `actions.yml` exist in the GH repo. Also ensures that the SHA exists on the Git tag, if the `tag` attribute is specified. The rest of the (currently spaghetti code) function is a lot of output and error(failure) and warning collection. Although it issues quite a few GH API requests, the rate limiter should not kick in (with an authenticated GH token). I opted to rely on the HTTP/1.1 `urllib.request` stuff, which has no connection-reuse. The alternative would have been to add a dependency. The algorithm roughly works like this, for each action specified in `actions.yml`: * Issue a warning and stop, if the name is like `OWNER/*` ("wildcard" repository). Can't verify Git SHAs in this case. * Issue a warning and stop, if the name is like `docker:*` (not implemented) * Issue an error and stop, if the name doesn't start with an `OWNER/REPO` pattern. * Each expired entry is just skipped * If there is a wildcard reference and a SHA reference, issue an error. Then, for each reference for an action: * If no `tag` is specified, let GH resolve the commit SHA. Emit a warning to add the value of the `tag` attribute, if the SHA can be resolved. Otherwise, emit an error. * If `tag` is specified: * Add the SHA to the set of requested-shas-by-tag * Call GH's "matching-refs" endpoint for the 'tag' value * Emit en error, if the object type is not a tag or commit. * Also resolve 'tag' object types to 'commit' object types. * Add each returned SHA to the set of valid-shas-by-tag. * For each "requested tag" verify that the sets of valid and requested shas intersect. If not, emit an error.

snazy force-pushed the gh-action-sha-tag-check branch 19 times, most recently from af91fe6 to 185416b Compare December 21, 2025 14:14

snazy force-pushed the gh-action-sha-tag-check branch 6 times, most recently from 6a82461 to a1796d0 Compare December 21, 2025 15:57

snazy force-pushed the gh-action-sha-tag-check branch 4 times, most recently from 4a17c00 to 41c0e43 Compare December 21, 2025 16:09

snazy changed the title ~~WIP - verify GH action tag/SHA combinations~~ Verify GH action tag/SHA combinations Dec 21, 2025

snazy marked this pull request as ready for review December 21, 2025 16:12

snazy force-pushed the gh-action-sha-tag-check branch from 40c514a to c62528e Compare December 28, 2025 19:49

raboof reviewed Feb 12, 2026

View reviewed changes

snazy force-pushed the gh-action-sha-tag-check branch from c62528e to 2a780ec Compare February 12, 2026 10:05

snazy marked this pull request as draft February 12, 2026 10:39

raboof and others added 7 commits February 14, 2026 09:33

setup-bazel: remove wildcard allowlisting

c127519

incorrectly introduced in https://github.com/apache/infrastructure-actions/pull/419/changes Also adding 0.18.0 as used in https://github.com/apache/skywalking-data-collect-protocol/blob/master/.github/workflows/ci.yaml

clean up remaining 'no expiration'

d1b0e7b

follow-up on apache#363, apparently missed some

avoid having both 'keep' and 'expires_at'

5b42b97

Remove 'expires_at' if there is also 'keep', since 'keep' currently takes precendence. We'll want to remove the 'keep' entries for most of these cases eventually, but let's do that gradually to reduce impact. See also apache#252

Fix coursier/cache-action reference

a7c1414

Add the "current" Git commit ID for the moving tag.

Fix leafo/gh-actions-luarocks reference

b9bc414

Update the moving tag `v5` with the current SHA.

move GH actions tags check to separate workflow

2714ffb

snazy force-pushed the gh-action-sha-tag-check branch from 7e0d2d2 to 2714ffb Compare February 14, 2026 08:34

snazy added 3 commits February 14, 2026 10:16

consider the 'keep' flag

0b8c39a

add convenience run-script

07cb018

add special handling for historic actions allowance against branches

ca6bcb9

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Verify GH action tag/SHA combinations#356

Verify GH action tag/SHA combinations#356
snazy wants to merge 10 commits intoapache:mainfrom
snazy:gh-action-sha-tag-check

snazy commented Nov 7, 2025 •

edited

Loading

Uh oh!

snazy commented Nov 7, 2025

Uh oh!

snazy commented Nov 17, 2025

Uh oh!

raboof commented Nov 18, 2025

Uh oh!

snazy commented Nov 18, 2025

Uh oh!

snazy commented Dec 21, 2025 •

edited

Loading

Uh oh!

raboof Feb 12, 2026

Uh oh!

snazy Feb 12, 2026

Uh oh!

raboof Feb 12, 2026

Uh oh!

raboof Feb 12, 2026

Uh oh!

raboof left a comment

Uh oh!

snazy commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

snazy commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

snazy commented Nov 7, 2025

Uh oh!

snazy commented Nov 17, 2025

Uh oh!

raboof commented Nov 18, 2025

Uh oh!

snazy commented Nov 18, 2025

Uh oh!

snazy commented Dec 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

raboof Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

snazy Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

raboof Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

raboof Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

raboof left a comment

Choose a reason for hiding this comment

Uh oh!

snazy commented Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

snazy commented Nov 7, 2025 •

edited

Loading

snazy commented Dec 21, 2025 •

edited

Loading