Today, consumers of the actions track the main branch for updates.
For example:
- uses: apache/infrastructure-actions/allowlist-check@4e9c961f587f72b170874b6f5cd4ac15f7f26eb8 # main
https://github.com/apache/iceberg-rust/blob/0b45d614af89be40b4d96c95ded227a38e55a606/.github/workflows/asf-allowlist-check.yml#L42
However, it is good practice to pin GH Actions to specific hashes. This is often recommended by Zizmor, a static analysis tool for GHA.
The problem is that as new commits are made to main, this causes drift where the pinned hash no longer matches the ref (main). It's also unclear if Dependabot will make updates to the dependency in this scenario.
This issue is a request for tag-based releases, such that we can pin the action against a specific 'release'.
For example, we'd like to have something like this:
- uses: apache/infrastructure-actions/allowlist-check@4e9c961f587f72b170874b6f5cd4ac15f7f26eb8 # v1.2.3
This would allow tools like Dependabot to recognize what version we're using, check for updates based on the Git tags for the repo, and Zizmor would not warn on drift.
Today, consumers of the actions track the
mainbranch for updates.For example:
https://github.com/apache/iceberg-rust/blob/0b45d614af89be40b4d96c95ded227a38e55a606/.github/workflows/asf-allowlist-check.yml#L42
However, it is good practice to pin GH Actions to specific hashes. This is often recommended by Zizmor, a static analysis tool for GHA.
The problem is that as new commits are made to
main, this causes drift where the pinned hash no longer matches the ref (main). It's also unclear if Dependabot will make updates to the dependency in this scenario.This issue is a request for tag-based releases, such that we can pin the action against a specific 'release'.
For example, we'd like to have something like this:
This would allow tools like Dependabot to recognize what version we're using, check for updates based on the Git tags for the repo, and Zizmor would not warn on drift.