Skip to content
mm
Install

Publish a release

Prepare, check, publish, and recover an mm release.

Releases are published by the protected GitHub Actions workflow. A manual workflow run builds packages for checking; it does not publish a stable release.

Before you start

You need permission to create release tags and approve the GitHub release environment. The release infrastructure must already be configured:

  • A dedicated Cloudflare R2 bucket connected to get.modmon.org, with HTTPS and TLS 1.2 or newer. Disable its public r2.dev URL.
  • A bucket-scoped read/write token. Store R2_ACCOUNT_ID, R2_ACCESS_KEY_ID, and R2_SECRET_ACCESS_KEY as protected environment secrets; store R2_BUCKET as an environment variable.
  • Protected v* tags: restrict creation/deletion, prevent updates, and require the release commit to be on master.
  • Cache rules that keep /releases/** immutable for one year, revalidate /manifest.json, and give root installers a short cache lifetime.

Test infrastructure changes using a separate bucket and hostname before using the public release bucket. Keep credentials out of the repository and logs.

Prepare the candidate

  1. Update core/Cargo.toml, Cargo.lock, and CHANGELOG.md to the same version.
  2. Run make quality from the repository root.
  3. Run local release preflight:
sh
./scripts/release-certify.sh preflight --output /tmp/mm-release-certification.json

The local report says incomplete until the hosted checks have passed. This is expected: local checks cannot verify all supported platforms or public downloads.

  1. Push the candidate commit and run the live workflows for that exact commit: robustness, runtime, secret, Vault, scheduler, remote, local TLS, and supplemental checks. All must succeed; skipped or older runs do not qualify.
  2. Create a new vMAJOR.MINOR.PATCH tag on that commit and push it. The version must match the package files and changelog. Never move an existing release tag.

Check publication

The tagged workflow builds x86-64 and ARM64 packages for Linux glibc, macOS, and Windows. It verifies uploads and clean installs before creating the GitHub Release. Check that:

  • All workflow jobs passed, including public installation tests.
  • The release includes binaries, source, checksums, manifests, and a passing release-certificate.json.
  • The public install guide works and mm --version reports the new version.
  • mm doctor --check-updates can read the published manifest.
  • Earlier versions remain downloadable from /releases/vMAJOR.MINOR.PATCH/.

Packages currently have no platform code signing or Apple notarization. The included package inventory and build statement do not imply signed provenance.

Recover a failed publication

Keep the workflow log and publication-log.json. Fix the reported upload, permission, DNS, or cache problem before retrying. An unchanged run may retry when already-uploaded files match byte-for-byte. Never delete or overwrite a historical release to make a retry pass.

If source changes are needed, use a new version and tag. Restore a latest-release manifest only from a previously verified release, with its matching installers. Do not point users at a partial release or test bucket.

To rotate publishing credentials, create a replacement bucket token, update the protected environment, test with a non-production rehearsal, then revoke the old token. Revoke suspected compromised credentials immediately and check release file hashes and access logs.