Repository navigation
ci: merge-and-auto-release workflow (draft-release approval) - #34
Merged
Carl723000 merged 2 commits intoJun 15, 2026
Merged
Conversation
Replace the hand-tagged release flow with a merge-and-approve one so a maintainer's only per-PR action is Merge/Reject, and releases auto-draft for one-click approval — preserving contributor attribution (PRs get *merged*, not re-applied). - add release-drafter: a draft GitHub Release is kept up to date as labelled PRs merge to main; next semver version inferred from PR labels; PRs auto-labelled from branch/title prefix - publish.yml: trigger on `release: published` instead of `v*` tag push; stamp package.json version from the release tag (no hand-bump, no tag/version mismatch) and drop the tag-vs-package.json guard; upload the .vsix to the existing Release without regenerating its notes - docs: CONTRIBUTING.md + CLAUDE.md describe the new flow; PR template maps change type -> release label This is "option A" (release-drafter) of two approaches; release-please is the documented alternative in the proposal issue. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Release Drafter reads its config from the default branch and the default GITHUB_TOKEN is read-only for fork PRs, so a pull_request autolabeler can't work for external contributions and fails on first introduction (config not yet on the default branch). Drop the pull_request trigger: drafting runs on push to main, maintainers set the version label at merge. Reword docs accordingly; the autolabeler block stays as a ready-to-enable option. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ildyria
reviewed
Jun 14, 2026
| contents: write # create / update the draft release | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: release-drafter/release-drafter@v6 |
Contributor
There was a problem hiding this comment.
Hi, thank you for addressing this issue.
As a security engineer, I totally support this change.
In the same line, please make sure that the commit is pinned instead of attached to a version such as @v6
Should release-drafter/release-drafter be compromised and publish a new evil release e.g. v6.6.6. You are compromised by supply chain.
If you pin the commit instead you won't be impacted.
Suggested change
| - uses: release-drafter/release-drafter@v6 | |
| - uses: release-drafter/release-drafter@693d20e7c1ce1a81d3a41962f85914253b518449 #v7.3.1 |
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.
Summary
This implements a merge-and-auto-release workflow so a maintainer's only per-PR action becomes Merge / Reject, and a release auto-drafts for one-click approval. Changes ship by merging PRs rather than re-applying them by hand, which preserves contributor commit authorship and the PR's merged status.
Companion discussion: #33 (the rationale + the release-drafter-vs-release-please options comparison). This PR implements the recommended option, Release Drafter; happy to swap it to release-please instead if you'd prefer.
How it works after this lands
feature→ minor,breaking→ major, else patch).release-drafter.ymlupdates a single draft GitHub Release (categorised notes + next semver version).publish.yml(now triggered onrelease: published) stampspackage.jsonfrom the tag, compiles, packages, and publishes to the VS Code Marketplace + Open VSX, attaching the.vsix.No manual
versionbump, nogit tag, no re-applying PRs by hand.Changes
.github/release-drafter.yml(new) — release-notes categories, label→semverversion-resolver, and anautolabelerblock kept ready to enable for same-repo PRs..github/workflows/release-drafter.yml(new) — runs on push tomainto keep the draft Release current (push-only, since fork-PR tokens are read-only — see the note in the file)..github/workflows/publish.yml— trigger switched frompush: tags: v*→release: types: [published]; the tag-vs-package.jsonguard is replaced by a build-time stamp version from the release tag step (so the tag is the single source of truth and a mismatch is impossible); the.vsixis uploaded to the already-published Release without regenerating its notes.CONTRIBUTING.md,CLAUDE.md,.github/PULL_REQUEST_TEMPLATE.md— document the new flow and map change type → release label.Unchanged: the
VSCE_PAT/OVSX_PATsecrets and the Marketplace / Open VSX publish steps.Recommended companion setting (not a file)
Enable branch protection on
mainrequiring a PR before merge, so Merge is the clean, gated path rather than a manual re-apply.How this was tested
0.0.0-testpre-release to confirmpublish.ymlfires onrelease: publishedand stamps the version.Type of change