Push the release to the main repository over ssh, not to origin - #296
Merged
Merged
Conversation
The git stage pushed the tag to `origin` and the branch to its tracking remote, so a release run from a clone whose `origin` is a fork tore the release apart: the tag landed on the fork and the commit on the main repository. The push target was also whatever `origin` happened to be, never checked against the repository actually being released. Resolve the push target by name instead: enumerate the remotes, match the one whose URL normalizes to the main repository (so a fork checked out as `origin` is never the target), and push the branch commit and the tag in a single atomic push, so a release can never split across remotes. When more than one remote matches, the first over ssh in git remote order wins and is named in the output. A dry run resolves and names the remote even from a branch that tracks nothing yet, so the push target can be checked from any clone before the release branch is ever checked out. Require ssh for that remote and refuse early, before anything is published, when the only match is https: a missing credential then fails upfront with a one-line `git remote set-url` fix, instead of halfway through a release with the package already on npm. The URL normalization the branch guard already used is shared from check-git-preconditions.sh so both call sites agree. Co-Authored-By: Guilherme Pereira Leme <69865537+GuiLeme@users.noreply.github.com>
Arthurk12
approved these changes
Sep 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
The git stage of the release script now resolves the push target by matching each remote's owner/name against the main repository declared in
scripts/lib/release-branches.json, so a fork checked out asoriginis never the target. The branch commit and the version tag go up in onegit push --atomic. The release remote must be reachable over ssh: when the only match is https, the script refuses up front and prints the exactgit remote set-urlfix. A dry run names the target remote even from a branch that does not track anything yet. The URL normalization is shared fromscripts/lib/check-git-preconditions.sh(renamed from check-release-branch.sh).Closes Issue(s)
None.
Motivation
A release from a clone whose
originis a personal fork came out torn: the tag went to the remote literally namedoriginand the branch to its tracking remote, splitting the release across repositories.More
Bare-repo fixtures reproduced the torn baseline on the old scripts and show commit and tag landing together on the main repository with the fix; refs read back on both bare repositories. Refusal paths (https-only match, no match) and the dry run from an untracked branch (scp-form ssh remotes, as reported) verified without mutation.
npx tsc,npm run lintand the 48test:unit(vitest) tests stay green.