From ca891732aaefcd85072f6c8689c679795a0b8cc4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sa=C3=BAl=20Cabrera?= Date: Tue, 13 Oct 2026 18:36:35 -0400 Subject: [PATCH] docs: Explain how to create and check release branches Explain how to run the workflows that create a release branch and check that it still builds before releasing from it, both from the Actions tab and with the GitHub CLI: CI on the branch, and a dry run of the Release workflow from `main`. Warn that the dry run must be started from `main`, since running the Release workflow from a tag releases it. --- CONTRIBUTING.md | 20 +++++++++++++++++++- docs/security-vulnerability-runbook.md | 4 +++- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c89ca992..b0682fee 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -66,7 +66,24 @@ To release a patch for an older version, e.g. `48.0.2` when `main` is on 49: 1. If `release-` (e.g. `release-48`) doesn't exist, run the [Release branch] workflow manually with the major version. It creates the - branch from the latest `v.*` tag. + branch from the latest `v.*` tag. Run it from the Actions tab, or + with the GitHub CLI: + ``` + gh workflow run release-branch.yml --ref main -f major= + ``` +1. Check that the branch still builds, since the toolchains and workflows may + have changed since its last release. Run the CI workflow on the branch, and + the [Release] workflow from `main` with the branch as `ref`. From the Actions + tab, pick the release branch in "Use workflow from" for CI, and `main` with + the release branch in the `ref` field for Release. With the GitHub CLI: + ``` + gh workflow run ci.yml --ref release- + gh workflow run release.yml --ref main -f ref=release- + ``` + The Release run is a dry run: it builds and smoke-tests the gems without + publishing them. Always run it from `main`; run from a tag, the workflow + releases that tag. Fix any failures through pull requests into the + release branch. 1. Merge the patches to release into `release-` through pull requests. 1. Run the [Release bump] workflow manually with branch `release-`. 1. Open both pull requests from the links in the workflow run's summary: @@ -87,3 +104,4 @@ To release a patch for an older version, e.g. `48.0.2` when `main` is on 49: [Release branch]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release-branch.yml [Release bump]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release-bump.yml [Release tag]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release-tag.yml +[Release]: https://github.com/bytecodealliance/wasmtime-rb/actions/workflows/release.yml diff --git a/docs/security-vulnerability-runbook.md b/docs/security-vulnerability-runbook.md index f3a83052..59a40cbb 100644 --- a/docs/security-vulnerability-runbook.md +++ b/docs/security-vulnerability-runbook.md @@ -44,7 +44,9 @@ supported. `ref`. This is a dry run: it builds and smoke-tests the gems but never publishes. - Fix any failures through pull requests into the release branch. + See [From a release branch](../CONTRIBUTING.md#from-a-release-branch) for + the commands. Fix any failures through pull requests into the release + branch. 1. **Collaborate on a fix in private.** Create the temporary private fork attached to the advisory and develop the fix there as a pull request