Skip to content

fix(ci): find release drafts when preparing VSIX releases - #112

Open
BinaryOutlook wants to merge 2 commits into
mainfrom
feat/release-draft-lookup
Open

BinaryOutlook wants to merge 2 commits into
mainfrom
feat/release-draft-lookup

Conversation

@BinaryOutlook

@BinaryOutlook BinaryOutlook commented Nov 13, 2026 •

Copy link
Copy Markdown
Owner

Fixes the false failure at the end of every Prepare VSIX release draft run. The draft was always created correctly, but the run still ended red.

Problem

scripts/promote-vsix.cjs creates the draft with gh release create --draft, then confirms it through GET releases/tags/{tag}. GitHub does not return drafts from that endpoint, because a draft has no Git tag until it is published. The final check therefore returned HTTP 404 and the job exited 1 after a successful upload. All five manual runs failed this way, from v0.3.0 to v0.5.1, and so did the v0.5.2 run (43470541838). Each draft was then checked and published by hand.

The duplicate guard had the same blind spot. It also used releases/tags/{tag}, and drafts have no tag ref, so neither of its checks could see a leftover draft from an interrupted upload.

Change

  • scripts/release-github.cjs: new findRelease(tag) searches the authenticated release list (releases?per_page=100, paginated). Both release workflows already request contents: write, which lets them see drafts in that list. If two releases or drafts share a tag, the run stops instead of picking one.
  • scripts/promote-vsix.cjs:
    • assertUnreleased(tag) replaces the pre-upload guard and now also blocks a leftover draft. The tag-ref check is unchanged.
    • confirmRelease(tag, publish) replaces the post-upload lookup. It keeps the draft and prerelease assertions, now with readable failure messages.
  • Unchanged: asset preparation, assertMain checks, the publish path in scripts/auto-release.cjs, and the step summary.

Neither script matches the release policy's isReleaseRelevant paths, so this change does not by itself make a VSIX release eligible. No documentation change is needed: the release procedure already describes the intended behavior.

Also fixed: command palette focus race in browser tests

PR validation attempt 2 failed one browser test on macOS (command-palette.spec.ts, "↑↓ moves the item selection"). The test pressed ArrowDown, but the first item stayed selected. openCommandPalette() focuses the filter input on the next animation frame (src/webview/editor/ui/menus.js), and only the input's own keydown handler moves the selection. The test pressed the key after a fixed 100 ms sleep, so on a slow runner the key could reach the editor first.

The second commit waits for the input to be focused before pressing keys. It does this in the arrow test and in the cursor-position test, which has the same race with Escape. This matches the fix 4b0a0da made to the wraparound test in the same file. No product code changes.

  • With animation frames delayed by 300 ms, the old sleep-then-press pattern reproduces the CI error (Received string: "command-palette-item selected"), and the new focus wait passes. This was a temporary local spec, since removed.
  • command-palette.spec.ts passed 60 of 60 locally: 12 tests, 5 repetitions each, using system Chrome.

CI history for this PR

  • Attempt 1 at 486bf54: Validate (macos) failed when the installed-VSIX harness timed out reconnecting to VS Code (browserType.connectOverCDP: Timeout 30000ms exceeded). This PR's files are excluded from the VSIX by .vscodeignore, and the same lane passed on main at 7982568.
  • Attempt 2 at 486bf54: Browser (macos, 1/3) failed with the command palette race described above.
  • 06f055b adds the test fix. Its CI result is pending.

Verification

Local, macOS, Node 26.11.1. The repository pins 24.21.0, which is not installed on this machine.

  • New test/unit/release-lookup.test.js, 8 of 8 passing. It uses a stubbed GitHub client that rejects any use of the releases/tags endpoint. It covers: a draft found by tag; a draft accepted in draft mode; a published release required in publish mode; failures for missing, wrong-state or prerelease results; a leftover draft blocking upload; an existing tag blocking upload; and two releases sharing a tag.
  • npm run test:unit: 494 tests, 475 passed, 0 failed, 19 skipped.
  • scripts/auto-release.cjs and scripts/promote-vsix.cjs both load.
  • Read-only run against this repository: confirmRelease('v0.5.2', true) finds the published release (id 444507922). assertUnreleased('v0.5.2') rejects reuse, and assertUnreleased('v0.5.3') passes.
  • node scripts/check-docs.cjs passed, and git diff --check is clean.

Not verified: the lookup has not run inside a release workflow, and there is no draft on the repository to test against. Drafts appeared in the release list for the maintainer's own login during the v0.5.2 release; the workflow's GITHUB_TOKEN has not been tested this way. GitHub documents that draft listings are visible to tokens with push access. The next manual release run will confirm it. No release or draft was created to test this change.

GitHub's releases/tags endpoint does not return draft releases, because a
draft has no Git tag until it is published. Prepare VSIX release draft
created a correct draft and then failed its final check with HTTP 404, so
every manual release run (v0.3.0 through v0.5.2) ended red.

Look releases up in the authenticated release list instead, which includes
drafts for workflows with contents write permission. The same lookup now
backs the duplicate guard, so a leftover draft from an interrupted upload
blocks a second draft for that version. Two releases sharing a tag stop
the run instead of picking one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@chatgpt-codex-connector

Copy link
Copy Markdown
Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-11-13T17:20:59.006402Z 486bf54 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

openCommandPalette() focuses the filter input on the next animation
frame, and the input's own keydown handler implements ArrowUp, ArrowDown,
Enter and Escape. Two tests pressed those keys after a fixed 100 ms sleep,
so on a slow runner the key could reach the editor instead. The arrow
navigation test failed this way on macOS in PR #112's validation.

Wait for the input to be focused, as the wraparound test already does
since 4b0a0da. With animation frames delayed by 300 ms, the old pattern
reproduces the CI failure and the new one passes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant