ci(release): resolve the next version without push credentials - #243
Conversation
The release workflow's verify job failed at "Resolve next version" with EGITNOPERMISSION on its first manual dry run. semantic-release runs `git push --dry-run` against the repository URL before any plugin, dry run or not, and aborts if that fails. The verify job deliberately has no credentials (persist-credentials: false, contents: read), so the check could never pass against the GitHub URL; the script's own comment claimed "no token" and that was true of the plugins but not of this check. eng/next-release-version.mjs now hands semantic-release the local checkout as the repository URL. Pushing HEAD to the branch it already is needs no network and no token and changes nothing, and the commit analyser still sees the full history and tags that the checkout fetched. Reproduced against a fresh clone of main with the network's credentials removed: the unmodified script fails with "Authentication failed" and EGITNOPERMISSION, the modified one prints 1.3.0, the same version the unmodified script resolves with credentials. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UWRpkQzKkNDYz3WiNgWvWU
PR SummaryLow Risk Overview
Reviewed by Cursor Bugbot for commit fbba9ff. Bugbot is set up for automated code reviews on this repo. Configure here. |
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. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
What does this change?
The first manual dry run of the
Releaseworkflow (run 36667479053) failed in theverifyjob at Resolve next version:semantic-release runs
git push --dry-runagainst the repository URL before any plugin, dry run or not (verifyAuthinindex.js), and aborts if that fails. Theverifyjob deliberately has no credentials (persist-credentials: false,contents: read), so the check could never pass against the GitHub URL. The script's own comment said "no token"; that held for the plugins but not for this check.eng/next-release-version.mjsnow passes the local checkout asrepositoryUrl. PushingHEADto the branch it already is needs no network and no token and changes nothing, and the commit analyser still sees the full history and tags that the checkout fetched. The credential-free design of theverifyjob is unchanged; nothing is added to its permissions or environment.This is the ordering problem ADR 0001 predicted for the release pipeline ("the first real test of the release pipeline is this release"). It predates the actor change and is not caused by any recent PR.
Type of change
feat— new behaviour (minor release)fix/perf— bug or performance fix (patch release)docs/test/refactor/chore/ci— no release!in the title, plus aBREAKING CHANGE:footer explaining the migration)Checklist
dotnet build CanKit.Pro.sln -c Releasesucceeds (run without-p:CI=truethis time; the change is a Node script outside the solution)dotnet test CanKit.Pro.sln -c Releasepasses — not run; no.csfile changedHow this was checked
Against a fresh clone of
main(780e512), with the container's authenticating proxy removed from the environment so that no credentials were available:fatal: Authentication failed→EGITNOPERMISSION, exit 1, the same failure as in CI1.3.0, exit 0. With credentials the unmodified script resolves the same1.3.0node eng/verify-release-config.mjs 1.3.0passes (breaking -> minor,releasing 1.3.0)What is not verified
verifyjob refuses to run offmain, so no pull-request check reaches it. Whether the dry run goes green is only known after merge, by dispatchingReleasewithdry_runchecked.releasejob (RELEASE_TOKEN, OIDC) have never run in this shape, so this may not be the last failure. The test step runs the full suite as its gate, so a flaky test such as Sdo_BlockUpload_Server_Deadline_Measures_Peer_Idle_Time_Not_The_Whole_Transfer failed once on ubuntu-latest #240 could also stop it.🤖 Generated with Claude Code
https://claude.ai/code/session_01UWRpkQzKkNDYz3WiNgWvWU
Generated by Claude Code