mirror of
https://github.com/cline/cline.git
synced 2026-08-30 17:20:20 +08:00
Saoud Rizwan
d618f8073a
* fix(vscode-rollout): align bundle versions in the stable AB workflow Found by Max in local testing: the union manifest's version (what the Marketplace and auto-update see) is the stitch input, but each bundle's About tab and telemetry extension_version read that bundle's OWN package.json — so the stable combined VSIX reported three different versions (dispatch input / main's 4.0.0 / legacy's 4.0.8) depending on where you looked. The nightly channel doesn't have this problem (nightlify.mjs stamps one version into everything); this gives the stable channel the identity-preserving equivalent: scripts/set-version.mjs stamps the dispatch version into each checkout after install, before its build. Also fixes a latent ab-package bug while restructuring the steps: the next-bundle build never ran build:sdk, so the @cline/* workspace deps had no dist and esbuild would fail on a fresh CI checkout (the workflow has never run end-to-end — the publish environment gate blocked pre-merge dispatches). Split install/build:sdk/align/build into separate steps, mirroring the nightly workflow. * fix(vscode-rollout): assert bundle sub-manifest versions in identity guardrails Greptile round on #12321: the stable guardrail didn't assert version at all. Went one further than the suggestion — both workflows' guardrails now also assert each bundle sub-manifest's version (and name, for nightly) matches the expected version, which is the check that actually regression- guards the set-version.mjs/nightlify.mjs stamping (About tab + telemetry extension_version read the sub-manifests, not the union). Expected version routed through env rather than interpolated into the script body. Adds the conventional paired test for set-version.mjs. * fix(vscode-rollout): don't fail the nightly run when the tag push is rejected First real combined publish (run 29454994164) published to both registries successfully but the run went red at the last step: the default GITHUB_TOKEN cannot create a ref whose commit modifies workflow files, and HEAD was the #12253 squash merge which rewrote this very workflow. There is no workflows permission grantable to the token, so this recurs any night HEAD touched .github/workflows. The tag is bookkeeping — mark the step continue-on-error so a successful publish isn't reported as a failure. (Today's missing tag was pushed manually.)