Build and draft a release from a version tag

[TheJoeIaut]

Cutting a release by hand means a self-contained publish, a run through Elgato's packer and an upload, with the version living in two files that have to agree with the tag. Pushing a v* tag now does all of it.

What it does

dotnet publish -r win-x64 --self-contained → streamdeck pack → a draft release with the .streamDeckPlugin attached. Nothing is public until you press Publish.

Two guards, both failing the run rather than releasing something wrong:

• The tag has to agree with the version. v2.0.1 wants 2.0.1.0 in manifest.json and 2.0.1 in the csproj. Disagreement is the mistake that ships a package Stream Deck won't accept as an update, or installs under the wrong version.
• The README has to have a ### <version> section. The release notes are taken from it, so the changelog and the release can't drift apart, and there's no second copy to keep in step.

Packing goes through @elgato/cli, which is Elgato's own packer and validates the manifest on the way through — so a plugin the Marketplace would reject fails here instead.

Testing

I can't run a GitHub Actions job from here, so what I verified locally, against the real repo files:

• The packer, end to end. Built a stub .sdPlugin from the repo's actual manifest.json, Images/, previews/ and PropertyInspector/, and ran the exact npx --package=@elgato/cli@1 streamdeck pack line from the workflow. It produced com.thejoeiaut.bitwarden.streamDeckPlugin and read the version as 2.0.1.0. streamdeck validate on the same folder reports 16 warnings and no errors (duplicate .svg/.png basenames, and action UUIDs not being dot-prefixed — both pre-existing, neither blocking).
• The version guard. v2.0.1 passes against the current files; v2.0.0 and v2.0.2 are both rejected with the message naming what disagrees.
• The notes extraction, run as the runner would see it (pulled the run: block straight out of the YAML, so the heredoc dedenting is tested too). 2.0.1 yields exactly its changelog section; a version with no section fails the step.

That last one caught a real bug while testing: the boundary originally only stopped at ###, so the oldest entry in the changelog ran on into the README's ## Requirements and everything after it. It now stops at any heading.

Not verified: the dotnet publish step and the gh release create step, neither of which I can run here. The publish line is the one already in BUILDING.md and in the existing CI's win-x64 job.

BUILDING.md gets a Releasing section covering the two prerequisites and the tag push.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NUWJUvGgLcxu2NYVMijj9K

---

Generated by Claude Code