cut-release

# Cut a meshery-operator release Publishing a release here is intentionally a one-action step: **flip the existing Release Drafter draft from draft to published.** Everything downstream is automated by GitHub Actions. ## How releasing works in this repo - `.github/workflows/release-drafter.yml` runs on **every push to `master`**. As PRs merge, it maintains a single **draft** GitHub Release whose tag auto-increments (the patch version bumps after each publish). There is always exactly one draft waiting to be published. This repo publishes **immutable** releases (assets cannot be added after publish), so the drafter also attaches the rendered CRD bundles to the *draft* on every master push - that is the canonical asset path, and it is why you must never hand-create the release. - Publishing that draft (the release `published` event) triggers: - `.github/workflows/multi-platform.yml` - builds the multi-architecture operator container images and pushes them to the registry, tagged with the released version. - `.github/workflows/sync-downstream.yml` - renders the CRD bundles, syncs the CRDs + chart versions into `meshery/meshery`'s Helm charts, and publishes the operator-versioned chart to `oci://ghcr.io/meshery/charts`. So the tag is already chosen and the notes are already drafted. Your job is only to make sure the just-merged PR is reflected in the draft, then publish it. **Do not create a tag, do not bump a version, do not write release notes by hand** - Release Drafter owns all of that. ## Steps ### 1. Confirm the Release Drafter run for the latest master commit has finished The draft only includes a PR after the drafter workflow run for that merge commit completes. If you publish too early, the just-merged PR is missing from the notes. ```bash # Latest master commit that should be in the release git fetch origin master --quiet && git rev-parse origin/master # Most recent Release Drafter runs (headSha should match origin/master, status "completed") gh run list --workflow="release-drafter.yml" --branch master --limit 3 \ --json databaseId,status,conclusion,headSha,createdAt ``` If the run for the current `origin/master` SHA is still `in_progress` (or absent because the push just landed), wait for it before publishing: ```bash gh run watch <databaseId> --exit-status ``` A `conclusion` of `success` for the run whose `headSha` matches `origin/master` means the draft is up to date (and its CRD bundles are attached). If the latest run **failed**, stop and surface that - do not publish stale notes or a draft missing its CRD assets. ### 2. Identify and inspect the draft ```bash # Tag of the current draft (there is normally exactly one) gh release list --limit 25 --json tagName,isDraft --jq '.[] | select(.isDraft) | .tagName' # Read the draft notes and confirm the recently merged PR appears in them gh release view <draftTag> --json tagName,name,isDraft,body --jq \ '{tag: .tagName, name: .name, isDraft: .isDraft, body: .body}' ``` Verify the merged PR the user is releasing shows up under one of the category headings. If it does not, the drafter run from step 1 has not yet indexed it - re-check step 1 rather than publishing without it. If more than one draft is ever returned, stop and ask the user which to publish rather than guessing - publishing the wrong one ships an unintended version. ### 3. Publish the draft Flipping `--draft=false` publishes it and fires the `published` event that drives the multi-platform image build and the downstream CRD/chart sync. Mark it `--latest` so it carries the "Latest" badge. ```bash gh release edit <draftTag> --draft=false --latest ``` ### 4. Confirm it published ```bash gh release view <draftTag> --json tagName,isDraft,isLatest,publishedAt --jq \ '{tag: .tagName, isDraft: .isDraft, isLatest: .isLatest, publishedAt: .publishedAt}' ``` `isDraft: false` and a non-null `publishedAt` confirm the release is out. Report the published version to the user and note that the multi-platform Docker build and the downstream CRD + Helm-chart sync workflows have been triggered by the release event. ## What to watch for - **Don't publish ahead of the drafter run.** The most common failure is publishing before the Release Drafter workflow has folded the merged PR into the notes, shipping a release whose notes omit the very change being released. Because releases here are immutable, the drafter also has to have attached the CRD bundles to the draft first. Step 1 exists to prevent exactly this. - **Never hand-author the tag or notes.** If you find yourself computing a version number or writing changelog entries, something is wrong - Release Drafter already did both. - **One draft only.** If `gh release list` shows zero drafts, no drafter run has occurred since the last release; if it shows more than one, ask the user which to publish.