From fa889c176a30c2ddc7725a22c2fe930d9877d6cc Mon Sep 17 00:00:00 2001 From: tiennm99 Date: Wed, 21 Oct 2026 18:00:29 +0700 Subject: [PATCH] docs: pin the release dry run to a branch carrying the Tauri workflow --- docs/release-process.md | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/docs/release-process.md b/docs/release-process.md index 65da842..85fc7d4 100644 --- a/docs/release-process.md +++ b/docs/release-process.md @@ -123,17 +123,30 @@ must equal the asset names exactly. A dry run creates a **draft** release, which does not show up on the public Releases feed and does not reach any client, legacy or Tauri. -1. Pick a throwaway tag with a suffix, like `v0.0.0-test`. The suffix - keeps the tag push from starting a publishing run; never use a plain - `vX.Y.Z` tag for a dry run, because pushing it publishes a release - marked latest. -2. On a scratch branch, set `Cargo.toml` `version` to `0.0.0-test`, run - `cargo build` locally to refresh `Cargo.lock`, and commit both files. - The release jobs build with `--locked`, so a stale `Cargo.lock` fails - them before any draft exists. The tag check also runs for drafts, so - the tag must point at a commit whose `Cargo.toml` version matches it. +1. Pick a throwaway tag with a suffix, like `v0.0.0-test`. The Tauri + `release.yml` triggers tag pushes only on plain `vX.Y.Z` tags and + refuses a suffixed tag outside a dispatch run, so the suffix keeps + the tag push from starting a publishing run. That guard exists only + in commits that carry the Tauri `release.yml`: the Win32 + `release.yml` it replaced triggers on `v*.*.*`, suffix included, and + publishes a non-draft release that GitHub marks latest. Never use a + plain `vX.Y.Z` tag for a dry run, because pushing it publishes a + release marked latest. +2. Cut a scratch branch from a commit that contains the Tauri + `release.yml`: the Tauri port branch before it merges, `main` after. + On it, set `Cargo.toml` `version` to `0.0.0-test`, run `cargo build` + locally to refresh `Cargo.lock`, and commit both files. The release + jobs build with `--locked`, so a stale `Cargo.lock` fails them + before any draft exists. The tag check also runs for drafts, so the + tag must point at a commit whose `Cargo.toml` version matches it. 3. Tag that commit and push the tag, then start the "Release" workflow - from the Actions tab (`workflow_dispatch`) with that tag as input. + (`workflow_dispatch`) from the scratch branch with that tag as input: + in the Actions tab, select the scratch branch under "Use workflow + from", or run + `gh workflow run release.yml --ref -f tag=v0.0.0-test`. + The default ref is `main`, which runs whatever `release.yml` `main` + holds; before the merge that is the Win32 pipeline, which builds one + exe and no `latest.json`, so the check in step 4 cannot pass. 4. Check the draft: it must hold exactly the six assets in the table above (with `0.0.0-test` as the version), and `latest.json` must list only `windows-x86_64` and `linux-x86_64`, with URLs equal to the @@ -144,7 +157,9 @@ public Releases feed and does not reach any client, legacy or Tauri. If a Tauri release is broken in the field, publish the Win32 sources again under a higher version with the "Release legacy" workflow -(`release-legacy.yml`): +(`release-legacy.yml`). GitHub dispatches a workflow only once its +file is on the default branch, so this workflow, and a dry run of it, +is available only after the Tauri port merges into `main`: 1. Pick a version `X.Y.Z` higher than every release in the field, so every client sees it as an update.