Problem
When pinning GitHub Actions to commit SHAs via github-action-commits, the generated release.yml has no way to include the corresponding semver version as a YAML comment:
# generated output
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
# desired output
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
Users naturally annotate the SHA with a comment in dist-workspace.toml, but the parser discards it. This makes the generated workflow harder to audit since reviewers and tools cannot tell what version a SHA corresponds to at a glance.
Proposed solutions
Option A: Structured config value
Accept a table in addition to a plain string:
[dist.github-action-commits]
# existing format still works
"actions/upload-artifact" = "ea165f8d65b6e75b540449e92b4886f43607fa02"
# new format with version annotation
"actions/checkout" = { commit = "de0fac2e4500dabe0009e67214ff5f5447ce83dd", version = "v6.0.2" }
When version is present, the generated YAML appends it as a comment on the uses: line. Backwards compatible: the value deserializes as an enum accepting either a plain string or a table.
Option B: Auto-resolve from GitHub API
At dist generate time, resolve the SHA to its corresponding semver tag via the GitHub API and append the comment automatically. Works with the current config format but introduces a network dependency during generation.
Problem
When pinning GitHub Actions to commit SHAs via
github-action-commits, the generatedrelease.ymlhas no way to include the corresponding semver version as a YAML comment:Users naturally annotate the SHA with a comment in
dist-workspace.toml, but the parser discards it. This makes the generated workflow harder to audit since reviewers and tools cannot tell what version a SHA corresponds to at a glance.Proposed solutions
Option A: Structured config value
Accept a table in addition to a plain string:
When
versionis present, the generated YAML appends it as a comment on theuses:line. Backwards compatible: the value deserializes as an enum accepting either a plain string or a table.Option B: Auto-resolve from GitHub API
At
dist generatetime, resolve the SHA to its corresponding semver tag via the GitHub API and append the comment automatically. Works with the current config format but introduces a network dependency during generation.