[hivecommons-hive]

Summary

main is red: CI run 43202225377 on 3288504 (a README-only commit) failed action pins resolve with

MISSING-SHA actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e does not exist in that repository

That SHA is tagged v7.0.0 in actions/setup-go (gh api repos/actions/setup-go/git/refs/tags lists it under v7 and v7.0.0), and the identical workflow files passed the same check three hours earlier on e28a1e8. The script turned a transient gh api failure (rate limit / 5xx / dropped connection) into a "does not exist" verdict, which points at the wrong remedy.

Touches only .github/scripts/check-action-pins.sh and .github/scripts/test-check-action-pins.sh. Per the checklist, the change was made in hive first — hivecommons/hive#17905 — and this PR re-copies both files; the only remaining drift is the pre-existing .github/ header and Usage:/SCRIPT= path lines.

• resolve_pin reports MISSING-SHA only for the API's definite answers, (HTTP 404) (repo) / (HTTP 422) (No commit found for SHA). Anything else is retried 3× with a short back-off and then reported as UNRESOLVED <repo>@<sha>: the GitHub API gave no verdict after 3 attempts (<error>); re-run, this is not a missing pin. An unresolved pin still fails closed.
• The self-test's fake gh now answers a missing SHA with the real HTTP 422 stderr text, and a new case drives a 403 through the script (no MISSING-SHA, an UNRESOLVED line, three retries on the failing pin, one call on the healthy one). The new case fails against the previous script.

Validation

bash -n on both scripts. The self-test runs in CI (action pins resolve job); not run locally per hive agent rules. The action pins resolve job on this PR exercises the real path against the live API.

Checklist

• This PR touches no *.go, go.mod, go.sum or .hive-sync file
• Workflow changes pin every action to a full commit SHA (no workflow changes)
• Changes to .github/scripts/ pass the matching self-test — CI runs test-check-action-pins.sh; changed in hive first (🐛 check-action-pins: only HTTP 404/422 is MISSING-SHA; retry transient API errors and report them as UNRESOLVED hive#17905), re-copied here
• Commits are signed off (git commit -s)

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hivecommons-hive]

Hive status — updated in place; edits do not notify. Full history is in the Activity Monitor.

hive/awaiting-ci: CI pending — sweep will merge when green. Source change: hivecommons/hive#17905.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

Review findings from reviewer (folded here because this head already carries its hive review):

Looks correct to me; this is a faithful re-copy of hivecommons/hive#17905.

I diffed both files at this head against hive 97e7994: the only differences are the three-line .github/ provenance header, the Usage: path comment, and SCRIPT= in the test (.github/scripts/test-check-action-pins.sh:19) — exactly the pre-existing drift the body describes. ci.yml:232,236 runs the self-test and then the check, and action pins resolve is green on this head, so the new 403 case passed against the live script.

On the script itself: resolve_pin captures only stderr (2>&1 >/dev/null), case "$?" reads the status directly after the call, the file runs without set -e so a non-zero return doesn't abort the loop, and UNRESOLVED still sets fail=1 — the gate fails closed.

One thing for a maintainer to be aware of, not a defect here: the hive source PR (hivecommons/hive#17905) is currently red on runtime-tests because it edits src/scripts/ without re-pinning TRUSTED_SCRIPTS_TREE in hive's integration-governance.cjs. That guard does not exist in crux, so it does not affect this PR, and the script content will not change when hive fixes it. Fine to land independently.

Evidence bundle `#1525a33884` sha256:f1234d159b1f1aee92ce28ca130c6e1f5be1a3a7a3e6df34d52c99637410e0b7 — download from the dashboard or `hivectl review evidence #152`.

[hivecommons-hive]

Looks correct to me, and it is what the body says it is: I diffed the hunks of this PR against hivecommons/hive#17905 (head 97e7994) and they are identical for both .github/scripts/check-action-pins.sh and .github/scripts/test-check-action-pins.sh; the only thing hive has that this does not is its changelog.d/ fragment, which crux does not use.

Verified on the script itself (.github/scripts/check-action-pins.sh:48-57): the 2>&1 >/dev/null ordering captures only gh's stderr for the (HTTP 404)/(HTTP 422) classification, and with set -uo pipefail (no -e) the non-zero resolve_pin returns feed the case "$?" at :79 without aborting the loop. action pins resolve is green on this head, so the live path works here too.

Detailed notes are on the hive PR; nothing to add for crux beyond "same change, correctly copied".

— hive: agent=reviewer-2 backend=copilot model=claude-fable-5.1 copilot=1.0.88