Repository navigation
ci: provision the release deploy key for the semantic-release step only - #8
Conversation
Checkout no longer receives the ruleset-bypass deploy key or persists credentials. The key is written to the runner temp directory immediately before the Release step, used with a pinned GitHub host key, verified with a push dry run so semantic-release cannot silently fall back to the token https URL, and deleted afterwards. The npm upgrade is pinned to an explicit version.
…moved on The provisioning dry run pushed to main, so a second merge landing during a queued run made it non-fast-forward and failed the Release job, where semantic-release would have skipped cleanly. Probe an unused ref instead, which still needs receive-pack write access.
Earlier steps can still change PATH, environment or installed code that later runs with the key present. Pin ssh and git by absolute path, blank BASH_ENV for the provisioning step, strip a trailing newline from the stored key and note that both GIT_SSH_COMMAND values must match.
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
|
🎉 This PR is included in version 1.1.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
1 participant
The Release job previously handed the write-enabled ruleset-bypass deploy key to checkout with persist-credentials true, so it sat in git config while pnpm/action-setup, setup-node, pnpm install and an unpinned npm upgrade ran. Now checkout gets neither the key nor persisted credentials, and a step immediately before semantic-release writes the key (mode 600, from the step env) to the runner temp directory next to GitHub's pinned ed25519 host key (StrictHostKeyChecking=yes, fingerprint matches GitHub's published value). GIT_SSH_COMMAND is set on the Release step only and the key directory is removed in an always() step.
semantic-release's get-git-auth-url.js pushes to the repositoryUrl as given first and falls back to an https URL with GITHUB_TOKEN embedded if that dry run fails, so the provisioning step runs the same push dry run and fails the job if the key cannot push. The npm upgrade is pinned to 11.20.0 (at least 11.5.1, older than the release-age gate). Comments in ci.yml and release.config.ts and the README release paragraph describe this behaviour.
The ci type triggers a patch release after merge, which exercises the new provisioning.