Improve the release story

[wokket]

Our release story atm isn't brilliant, is effectively undocumented, and is different to what I do elsewhere so I get confused every time I do it. We currently have no ability to push pre-release nuget packages, and making a release is a multi-step operation.

Where I think I'd like to get to is:

• Create a release in Github, configuring the version number (including pre-release suffixes) as a new Tag when saved.
  • And release notes etc etc
• Release pipeline runs automatically on new tag/new release to Build and push the release
• Release Pipeline is the same as the CI build, but actually pushes artifacts (containers, nugets etc) downstream
  • Put another way, I want as much of the release pipeline run as CI as possible, so the CI can catch as many issues as possible
  • I'm probably ok with skipping the tests in the Release pipeline because they are all run on PR/CI builds
• Light docco item explaining this process for future peeps

I might get a chance to play with this over the next day or two, otherwise it will a couple of weeks before my next chance... if anyone else has feedback/opinions, or wants to contribute please join in the conversation.

[erikbra]

I reviewed the implementation in draft PR #804 against the complete description of this issue.

Coverage in #804:

• A GitHub release is authored with the complete SemVer tag, including prerelease suffixes, plus release notes.
• Publishing the release automatically starts the release workflow against that tag.
• Relevant pull requests and pushes run the same packaging jobs without publishing; the release run reuses that graph and adds publication.
• Stable and prerelease NuGet packages use the complete tag as PackageVersion.
• GitHub assets, checksums, release manifest, Docker image, NuGet packages, WinGet update, and Homebrew cask have explicit publication jobs/policies.
• Tests remain in normal CI and are intentionally skipped by the release event, as suggested here.
• The release and recovery process is documented for future maintainers.

The release notes themselves remain part of authoring the GitHub release, while the workflow is responsible for validating, building, and publishing it.

Follow-up work has been split into separately reviewable issues:

• Migrate the Docker image to grate-devs/grate #799 — migrate the Docker image to grate-devs/grate
• Migrate the WinGet package identity to grate-devs.grate #800 — migrate the WinGet package identity to grate-devs.grate
• Migrate the Homebrew tap to grate-devs/homebrew-cask #801 — migrate the Homebrew tap to grate-devs/homebrew-cask
• Update distribution documentation after ownership migrations #802 — update all distribution documentation and examples after those destinations are live
• Redirect legacy erikbra.github.io/grate documentation URLs #803 — redirect legacy erikbra.github.io/grate documentation URLs

All five follow-up issues are assigned to @erikbra. I did not find an aspect of #796 that is missing from the draft implementation or the linked follow-up work.

[wokket]

He's baaack 🤩

I've been away for a few weeks but will have a look at these soon, thank you 🍻