Keep the original order (push before publish) to preserve the safe
failure mode, but replace the cherry-pick with rebase and add a
3-attempt retry loop to shrink the race window.
Move the git push operation to the end of the publishing process to minimize race conditions. Replace the cherry-pick logic with a rebase onto origin/main and a retry loop to ensure the release commit is pushed successfully even if concurrent merges occur.
The SDK build step imported earlier in publish.ts does process.chdir into
packages/sdk/js and never restores it, so the relative path to
packages/kilo-vscode/CHANGELOG.md later in the release block resolved to a
missing file. The read silently fell through to an empty string and the
GitHub release body ended up as the 'No notable changes' default even
though the CHANGELOG in the release commit had all the entries.
Resolve the path relative to this script via fileURLToPath so it works
regardless of cwd.
The version job ran `bunx changeset version` to consume .changeset/*.md
files and update CHANGELOG.md, but the publish job (which commits and
pushes) ran on a separate runner with a fresh checkout — discarding all
changelog changes. This caused CHANGELOG.md to stay stuck at 7.2.1
despite 9 subsequent releases.
Move changeset consumption into publish.ts so it runs on the same runner
that commits. Extract release notes from the updated changelog and pass
them to `gh release edit` so GitHub releases also get correct notes.
When the publish workflow is dispatched with pre_release=true, the CLI
and SDK packages are now published to npm under the "rc" dist-tag with
a semver prerelease version (e.g. 7.1.24-rc.202604081425) instead of
going to the "latest" tag as a stable release.
This ensures that pre-release VS Code extension builds ship with a
matching pre-release CLI on npm, so users on the stable channel are
never affected by pre-release publishes.
Josh Lambert