fix(release): find an existing draft by listing, upload to it by id

[Leo310]

What

Re-pointing the unpublished 2.3.0 tag created a second draft instead of updating the first. GitHub's releases/tags/<tag> endpoint never returns drafts, so the workflow's lookup 404'd and took the "no release yet" path. The mid-upload "was it just published?" re-check used the same endpoint, so it would also have failed on a draft.

• Find the tag's release by listing releases (--paginate, with the tag passed to jq via --arg):
  • none → create the draft, as before
  • more than one → fail and ask for the strays to be deleted
  • one published → refuse, as before
  • one draft → update it by id
• Draft notes are set with PATCH releases/<id>, restating tag_name. A PATCH without it renames a draft's tag to untagged-<hash>, verified against a draft on an existing tag, which detaches the draft from its tag. That is probably also how 2.1.1 was published as untagged-<hash>.
• Assets are replaced by id through the uploads API (delete the same-named asset, then upload), with a paginated lookup. gh release upload <tag> also failed to find a draft in testing, so it's no longer used.
• The job has a per-tag concurrency group (queued, not cancelled), so two pushes of the same tag can't both create a draft.

How I tested it

• Ran the step body with bash three times in a row against a scratch draft on an existing tag (2.3.0-beta.1, whose release had been deleted):
  • Every run updated that same draft.
  • The tag stayed 2.3.0-beta.1.
  • The body and main.js were the last run's, and exactly one release existed for the tag.
  • The scratch draft was deleted afterwards.
• A crafted tag like the one in the review matches nothing.
• The listing finds the current 2.3.0 draft, which releases/tags/2.3.0 404s on.
• The real test is the next step of the 2.3.0 release: re-pointing the tag after the notes restructure must update draft 398002294, not add a second one.

AI assistance: Claude Code found this during the 2.3.0 release, when a re-pointed tag created a duplicate draft, and wrote the fix at Leo's request. The tag_name rename was found while testing the fix. Leo still needs to review the workflow change.

Checklist

• bun run check, bun run format, bun run lint, and bun run test pass locally (no source changes; workflow YAML validated)
• I tried the change in a real Obsidian vault (or explained above why that isn't applicable): not applicable, CI-only change
• I read CONTRIBUTING.md, including the section on AI assistance
• If this adds a provider, a bundled skill, a built-in tool, or changes manifest.json: n/a

[greptile-apps]

Confidence Score: 5/5

[High risk] Changes how release artifacts are uploaded in CI.

The PR appears safe to merge; no outstanding blocking finding was established.

Summary

The workflow now finds drafts by listing releases, updates them by ID, and replaces assets through the uploads API. The latest changes make a failed listing stop the job and skip uploads from runs whose tag has since moved.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Tag push builds assets] --> B{Remote tag still points to build commit?}
  B -- No --> C[Skip upload]
  B -- Yes --> D[List releases for tag]
  D --> E{Matching releases}
  E -- None --> F[Create draft]
  E -- Multiple --> G[Fail]
  E -- One published --> G
  E -- One draft --> H[Update notes and replace assets by ID]
  H --> I{Still a draft?}
  I -- No --> G
  I -- Yes --> J[Complete]

Loading

_{Reviews (3) · Last reviewed commit: "fix(release): pipefail on the release lo..."}