ci: pin GitHub Actions to commit SHAs

[rivernate]

Pins every third-party uses: action reference in this repo's workflows to its resolved commit SHA, keeping the original version tag as a trailing comment (e.g. actions/checkout@d23441a... # v6).

Why: a mutable version tag can be retargeted by the action's owner after the fact, with no PR or diff ever appearing in this repo — "Dependabot bumped a trusted action to a newer version" and "a tag got silently retargeted to something malicious" are indistinguishable from CI's point of view. A SHA pin is immutable, so that retargeting can't affect an already-pinned workflow. This doesn't guard against a legitimately-tagged new release that's malicious at the source — required checks still only prove the pipeline runs, not that new code is trustworthy — but it closes the silent-retarget gap.

Dependabot understands this pattern natively: it recognizes the trailing version comment and keeps both the SHA and the comment in sync on future bumps, so this doesn't change how version updates flow through this repo.

Context: derivita/infrastructure#1856

Mechanically generated: a script scanned every file under .github/workflows/ (3 total), resolved each uses: line's tag to a commit SHA via the GitHub API (gh api repos/OWNER/REPO/commits/REF --jq .sha), and rewrote it in place. 2 file(s) needed changes (shown in this diff); any others were already SHA-pinned.

Also adds .github/dependabot.yml with a github-actions ecosystem entry — this repo had none, so without it the SHA pins above would have no update path (the "Dependabot keeps this in sync" claim above wasn't true until this file existed). Covers github-actions only; the repo's existing npm updates were running as Dependabot security updates, which don't need a config and aren't affected either way.

Same script and pattern already validated end-to-end on derivita/agent-plugins#141 (full /pre-pr gate: fleet review, correctness pass, prose-vs-diff, actionlint/zizmor — all clean). Skipping a repeat full gate here per that validation; see derivita/infrastructure#1856 for context.

[wbhumphrey]

The SHA pins themselves check out — I verified all seven against upstream tags (actions/checkout v4.4.0, setup-node v4.4.0, upload-artifact v4.6.2, download-artifact v4.3.0, setup-bazel 0.8.5, codeql-action v3.37.8, upload-release-action v2). Every SHA is the commit the tag points at.

One blocking problem: the rewrite dropped the /init and /analyze subpaths from the two CodeQL steps, so the CodeQL workflow will fail to resolve an action.

[wbhumphrey]

Both blocking findings are fixed correctly, and the fixes are minimal — the two CodeQL steps regained their /init and /analyze subpaths with the SHA and comment untouched. I re-checked every uses: line across all three workflow files: no other subpath action lost its path, and the seven SHAs I verified against upstream tags on the first pass are unchanged. Approving.

Adding dependabot.yml is a good catch and closes a real gap in the PR's own reasoning: without a config, the "Dependabot understands this pattern natively, so this doesn't change how version updates flow" claim wasn't true for the github-actions ecosystem, since version updates there require a config entry. It's true now.

One stale-prose note, not worth a force-push on its own but worth fixing if you touch the description again: it still says "2 file(s) needed changes ... No other content changed," and the PR now carries three files including a hand-written config that isn't a SHA rewrite.

Left the # v4 comment-precision thread open — that's a house-convention call for Brad, not something I want to resolve on his behalf.

[wbhumphrey]

The four new commits move this PR from a CI-pinning change into a build-system repair, and the repair isn't finished yet — build is still failing at 5c95bf4. So this is a COMMENT rather than an approval; the SHA pinning I approved last round is unaffected and still looks right.

For the record on the CI signal: build has been red at every commit on this branch, including d71c349, so none of these commits broke it. But a871e50, 22d41b4, 96ab974 and 5c95bf4 are all attempts to make it green, and it isn't green, so I don't have a working build to check any of this against. If you can paste the current failure, I can look at whether it's the finding below or something further down the pipeline.

One blocking item, in commonjs/export_testdeps.js: PropertyReplacer needs a default import rather than a named one. Details inline — the short version is that the namespace is the class there, unlike goog.crypt on the line above where the named form is correct. Since export_testdeps.js is the entry point for commonjs_testdeps, which npm test runs, that one is on the path to the failure you're chasing.

The direction of 96ab974 is right, and worth saying explicitly: package.json pins google-closure-library@~20200315.0.0, which predates the ES-module build of the library entirely. Those files are goog.provide/goog.module, so the old import * as x from '../../closure-library/.../base64.js' was never going to bind no matter where the path pointed — which is why the symlink alone (22d41b4) didn't fix it. goog: specifiers are the actual mechanism, and switching the import * as forms to defaults along the way is exactly right; import * as from a goog: specifier is a hard compiler error.

Two things that follow from that, neither blocking:

The conversion is partial. Fourteen files still import closure-library by path — every *_test.js and all of experimental/runtime/. They aren't in the --js= list so they don't affect the artifact, but commonjs_out rewrites the test files and test_closure loads them, and the tree now carries two idioms for the same import. Worth either finishing the sweep or leaving a note about where the boundary is and why.

a871e50 is a real bug fix and the commit message describes it accurately — two exec() calls sharing one callback meant cb() fired on whichever bazel build finished first. Nothing to add.

Last, the framing: title and description still describe this as pinning actions to SHAs, and the body still says "2 file(s) needed changes ... No other content changed" against a nine-file diff that now includes a build-system fix and an import migration across six JS files. I'd rather see the build fixes as their own PR — the pinning change is reviewable in one pass and the closure migration is not — but if they stay together the description needs to say what's actually in here. Flagging, not editing.

[wbhumphrey]

Both of my substantive findings are fixed correctly. PropertyReplacer is a default import now, and the symlink guard uses lstatSync so a dangling link no longer throws EEXIST. The trimmed comment is accurate about what the symlink is still for.

One new blocking item, introduced by the cleanup half of that second fix: remove_gen_files now runs rm -rf against ../closure-library unconditionally. That path predates this branch — it's the sibling-checkout convention already in gulpfile.js on main — so on a machine that has a real closure-library clone there, npm run clean deletes it recursively. rm -rf doesn't follow symlinks, so the case you were targeting is fine; it's the case you weren't targeting that's destructive. A [ -L ] guard, or an lstatSync().isSymbolicLink() check next to the code that creates the link, closes it. Suggestion inline. That one's on me for asking for the cleanup without saying what it should be guarded on.

On the CI story: the root-cause explanation in the export_testdeps.js thread doesn't survive contact with this commit's results. build and Analyze (javascript) are both still failing at 907e2a3 with the default import in place, so the ERR_MODULE_NOT_FOUND on commonjs_out/debug.js has another cause — or at least another cause behind it. Worth getting the current log before concluding that layer is done; the import fix was necessary, but it doesn't look sufficient.

Everything else from the last pass stands unchanged: the conversion is still partial (the *_test.js files and experimental/runtime/ remain on path imports), and the title and description still describe this as an actions-pinning PR rather than the build repair it has become.