Compiler emits annotated tag object SHA for gh-aw-actions pins; Renovate rewrites to peeled commit SHA

[rspurgeon]

Summary

gh aw compile appears to emit the annotated tag object SHA for
github/gh-aw-actions tags, while Renovate later rewrites those same action
references to the peeled commit SHA for the same tag.

This creates recurring churn in downstream repositories even when the version
comment does not change.

Example

For github/gh-aw-actions tag v0.68.1:

git ls-remote https://github.com/github/gh-aw-actions.git \
  refs/tags/v0.68.1 refs/tags/v0.68.1^{}

Returns:

2fe53acc038ba01c3bbdc767d4b25df31ca5bdfc  refs/tags/v0.68.1
ea222e359276c0702a5f5203547ff9d88d0ddd76  refs/tags/v0.68.1^{}

So:

• 2fe53acc... = annotated tag object SHA
• ea222e35... = peeled commit SHA

In a downstream repo, gh aw compile/generated workflow content used:

uses: github/gh-aw-actions/setup@2fe53acc038ba01c3bbdc767d4b25df31ca5bdfc # v0.68.1
uses: github/gh-aw-actions/setup-cli@2fe53acc038ba01c3bbdc767d4b25df31ca5bdfc # v0.68.1

Renovate later proposed:

uses: github/gh-aw-actions/setup@ea222e359276c0702a5f5203547ff9d88d0ddd76 # v0.68.1
uses: github/gh-aw-actions/setup-cli@ea222e359276c0702a5f5203547ff9d88d0ddd76 # v0.68.1

The version comment stayed # v0.68.1; only the SHA changed.

Why This Matters

This seems like a real normalization mismatch, not just cosmetic output:

1. It creates ongoing Renovate noise in downstream repos.
2. It makes gh aw output disagree with ecosystem tooling that expects a pinned
   action to use the underlying commit SHA.
3. The tag object SHA is the less stable thing to pin.

The last point is especially relevant for gh-aw-actions: its sync workflow
creates annotated tags via git tag -a, and currently deletes/recreates
existing tags before pushing them again:

if git tag -d "$TAG" 2>/dev/null; then
  ...
fi
if git push origin ":refs/tags/$TAG" 2>/dev/null; then
  ...
fi

git tag -a "$TAG" -m "Sync from gh-aw@$TAG"
git push origin "$TAG"

So the annotated tag object SHA can churn independently of the commit the tag
ultimately points to.

Expected Behavior

When gh aw resolves an action tag to a pinned SHA, it should emit the
peeled commit SHA, not the annotated tag object SHA.

For the example above, I would expect:

uses: github/gh-aw-actions/setup@ea222e359276c0702a5f5203547ff9d88d0ddd76 # v0.68.1
uses: github/gh-aw-actions/setup-cli@ea222e359276c0702a5f5203547ff9d88d0ddd76 # v0.68.1

Possible Root Cause

This looks like the resolver may be reading the tag ref object's SHA directly
instead of peeling annotated tags to the underlying commit.

Suggested Fix

• Peel annotated tags before writing action pins into generated workflows.
• Standardize on commit SHAs for emitted uses: pins.
• Add a regression test for github/gh-aw-actions/setup / setup-cli showing
  that the emitted SHA matches refs/tags/<tag>^{} rather than
  refs/tags/<tag>.

Related Context

This seems related in spirit, but not identical, to pinning inconsistencies
already discussed in #23088.

[pelikhan]

/scout is there a cli tool to run renovate locally