[Marc-André Moreau (mamoreau-devolutions)]

Summary

This PR also prepares 12.1.2: rust/prepare-release.ps1 -Version 12.1.2, no hand edits. That bumps the three crates, the exact rustolonia-sys pin, release-manifest.json and SharedVersion.props, clears host-checksums.txt, and refreshes Cargo.lock and the rustolonia entries in the in-repository apps' lock files. After it merges, the 12.1.2 release is the one-dispatch command below.

After the version bump is merged, a single dispatch of Release now does the whole release:

gh workflow run release.yml --repo Devolutions/rustolonia --ref master -f phase=all -f version=12.1.2 -f publish_crates=false -f draft=false

• New phase=all (now the default). It runs version → build (6 RIDs) → stage-release (unchanged) → new pin-release → existing publish → optional publish-crates.
• pin-release (contents: write):
  • checks out the built commit (github.sha) and downloads the staged artifact from the same run, then re-verifies it with sha256sum --check;
  • fails if master no longer points at the built commit or if vX.Y.Z already exists;
  • runs prepare-release.ps1 -Checksums -SumsFile … -CommitAndTag -SourceRevision $GITHUB_SHA, which makes "Pin rustolonia X.Y.Z release host checksums". That commit's parent is the build commit and it changes only host-checksums.txt. The script also creates the annotated tag vX.Y.Z and refuses a dirty tree, an existing tag, a different HEAD, or any other changed file;
  • pushes master and the tag with one git push --atomic (never forced). If master moved or the tag appeared in the meantime, nothing is pushed. I checked this behaviour against a local bare repo.
• publish / publish-crates are reused rather than copied:
  • With phase=all they take the artifacts from the same run, use github.sha as the build source, and also require the tag to point at the commit pin-release pushed.
  • The existing check still applies: the tag must descend from the build source and differ from it only by host-checksums.txt.
  • With phase=publish the behaviour is unchanged: it validates the build_run_id run and downloads from it.
• phase=build / phase=publish keep working as the manual fallback. With phase=all, the version job also rejects build_run_id, and rejects draft combined with publish_crates, before the expensive builds start.
• Push credentials: the push uses GITHUB_TOKEN, or the optional repository secret RELEASE_PUSH_TOKEN when it is set.
• Docs: the "Releasing" section of rust/PRODUCTIZATION.md now describes the one-dispatch path first, including recovery, and keeps the manual path as a fallback (examples updated to 12.1.2).

osx-x64 on Apple silicon

The macos-15-intel jobs were the slowest in both workflows. In CI the release-gate job took about an hour, against ~30 min for osx-arm64. In the release, the host build took 21 min; the next slowest took 13.

• Release
  • The osx-x64 host is now built on macos-14, using the x86_64-apple-darwin Rust target.
  • Rosetta 2 is installed if missing.
  • The standalone-app smoke tests still build and launch an x64 app; test-host-download.ps1 now passes --target in that case.
• CI
  • osx-x64 is dropped from the native release gate.
  • The existing cross-build (osx-x64) job on macos-14 now also packages the host tarball and runs the same standalone-app test under Rosetta. Every PR therefore rehearses the release's osx-x64 path.
• Trade-off: x64 macOS no longer runs the managed test suite or tests on real Intel hardware in CI.

Owner configuration

Nothing is needed for 12.1.2. Today master has no branch protection and the repository has no rulesets, so GITHUB_TOKEN with contents: write can push. As before, the workflow-permissions setting must allow contents: write; it already does, because publish uses it.

If master or v* tags are protected later, do one of these:

• let GitHub Actions bypass those rules, or
• add a repository secret RELEASE_PUSH_TOKEN: a fine-grained PAT for an account on the bypass list, with Contents: Read and write on this repository only.

Rules that require signed commits are not supported by this path; use the manual path.

A checksum commit pushed with GITHUB_TOKEN does not trigger Avalonia Rust CI. That is expected.

Verification

• pwsh rust/tests/test-build-app.ps1 passes. It now exercises -CommitAndTag in a scratch git repo: the dirty-tree and wrong-source refusals, the parent and tag target, the annotated tag, a commit that touches one file, an existing tag, and no-op checksums.

• The workflow YAML parses and the job graph is as intended. actionlint was not available locally.

• Not run: the workflow itself. These parts are checked only by reading:

  • the !cancelled() job conditions;
  • download-artifact@v4 reading the same run's artifact when no token is passed;
  • gh run rerun --failed reusing artifacts and outputs from the earlier attempt.

  The first phase=all run (12.1.2) is the real test.

• No new third-party actions; only actions/checkout and actions/download-artifact are used, per the CI action policy.

🤖 Generated with Claude Code