[codex] Fix action Corepack bootstrap

[llun]

Summary

Fixes the GitHub Action bootstrap for Node 24 hosted runner actions without downloading Yarn manually.

The original failure came from resolving npm with getRuntimeCommand('npm'), which builds an absolute path next to process.execPath. On the hosted action runtime that directory contains node, but not npm or corepack, so the absolute npm path failed with ENOENT even though npm install -g corepack works when npm is resolved from PATH.

This PR now:

• keeps the action runtime Node directory first on PATH for spawned setup commands
• resolves bootstrap package-manager commands from PATH instead of the runtime-local bin directory
• uses Windows-safe command shims for spawnSync without shell: true (npm / npm.cmd, corepack / corepack.cmd)
• installs Corepack with npm install -g corepack
• runs corepack enable before corepack yarn install
• keeps scoped command/status logs and carries command labels with spawn results
• tests the critical guards: no runtime-local npm/corepack lookup, Windows .cmd suffix support, and install -> enable -> yarn ordering

The temporary workflow changes used to run Sample from branch refs are not in the final diff; the main guard is restored.

Validation

• node --check action.mjs
• yarn test action.test.js
• yarn test (50 tests)
• Diagnostic run proving the original absolute runtime npm path fails with ENOENT while PATH npm succeeds: https://github.com/llun/feeds/actions/runs/25512251416
• Branch-ref sample run passed with the smaller Corepack fix: https://github.com/llun/feeds/actions/runs/25512570152
• Latest PR checks pass via gh pr checks 819:
  • test: https://github.com/llun/feeds/actions/runs/25513815228/job/74879396181
  • Analyze (actions): https://github.com/llun/feeds/actions/runs/25513813614/job/74879402928
  • Analyze (javascript): https://github.com/llun/feeds/actions/runs/25513813614/job/74879402836
  • CodeQL: https://github.com/llun/feeds/runs/74879531395

[gemini-code-assist]

Code Review

This pull request refactors the command execution logic in action.mjs by introducing helper functions for formatting commands, summarizing results, and asserting success. It removes the steps for globally installing and enabling corepack, opting instead to use the bundled version. Additionally, it improves logging by outputting environment details and command results. The test suite was updated to verify the removal of corepack installation steps. I have no feedback to provide.

[llun]

Review: Fix action Corepack bootstrap

The core fix — switching from getRuntimeCommand('npm') to plain PATH-resolved npm — is the right direction based on the diagnostic findings. The assertCommandSucceeded refactor also improves error reporting significantly. However, there are four issues to address before merging:

Must fix

1. corepackCommand path may not be valid after PATH npm -g install — getRuntimeCommand('corepack') points to the runtime bin dir, but that dir reportedly lacks both npm and corepack. If npm install -g corepack puts corepack in a different prefix, the enable and yarn install steps will still fail. Needs verification or a fix. (inline comment on action.mjs line 75)

2. Debug console.log statements left in — four path-logging lines are diagnostic artifacts that should be removed (or gated behind RUNNER_DEBUG). (inline comment on action.mjs lines 76–79)

Should fix

3. Label string duplicated at every call site — passing the same string to both runCommand and assertCommandSucceeded is error-prone. Suggested refactor in inline comment. (inline comment on action.mjs lines 81–84)

4. Test lost the ordering invariant — the new test checks string existence but no longer verifies that install happens before enable. Also, string-existence tests are fragile against future refactors. Suggested fix in inline comment. (inline comment on action.test.js)

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 97f050e04d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[llun]

Follow-up review

All four points from the previous review are addressed cleanly. CI is green.

Resolved

1. ✅ corepackCommand fragility — getRuntimeCommand is gone. enable corepack and yarn install now invoke 'corepack' via PATH, consistent with how npm install -g corepack deposits the binary on the runner's global npm prefix (which is on PATH).
2. ✅ Debug console.log lines removed — the four diagnostic path-prints are gone. The remaining per-command log lines from runCommand/assertCommandSucceeded are operationally useful (matches the PR description's "keeps command/status debug logs for future runner changes") and are well-scoped.
3. ✅ Label duplication eliminated — runCommand now returns { label, result } and assertCommandSucceeded consumes the combined object, so each call site names the step exactly once. Matches the suggested refactor.
4. ✅ Test ordering invariant restored — installIndex < enableIndex < yarnIndex is now asserted, plus the new t.false(source.includes("getRuntimeCommand(...)")) assertions guard against regressions of the original bug.

Minor nit (non-blocking)

• The PR description still says "keeps using the runtime-local corepack path after npm creates it", but the implementation no longer does that — it uses PATH-resolved corepack. Worth tweaking the description before merging so future readers don't get a wrong mental model from the commit/PR history.

LGTM aside from that documentation nit.

---

Generated by Claude Code

[llun]

Follow-up review documentation nit addressed. The PR description now says the action uses PATH-resolved npm/corepack shims (including .cmd on Windows) instead of the old runtime-local corepack wording.