ci: add Rust release workflow targeting GitHub Release assets#1297
Conversation
Member
Author
|
This pull request is part of a Mergify stack:
|
This was referenced Apr 23, 2026
Contributor
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🔴 ⛓️ Depends-On RequirementsWaiting for:
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for:
This rule is failing.
🔴 🔎 ReviewsWaiting for:
This rule is failing.
🟢 🤖 Continuous IntegrationWonderful, this rule succeeded.
🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR descriptionWonderful, this rule succeeded.
|
jd
force-pushed
the
devs/jd/worktree-rust-port/add-rust-release-workflow-targeting-github--48adf3e4
branch
from
2da50c7 to
a2cca7a
Compare
Member
Author
Revision history
|
This was referenced Apr 23, 2026
jd
force-pushed
the
devs/jd/worktree-rust-port/add-port-inventory-guard-catch-un-ported-python--4a71d672
branch
from
b887a4a to
fddda52
Compare
jd
force-pushed
the
devs/jd/worktree-rust-port/add-rust-release-workflow-targeting-github--48adf3e4
branch
from
a2cca7a to
cb257f5
Compare
Starts distributing the static Rust binary alongside the existing PyPI wheel. Both pipelines run on every published GitHub Release until the Phase 1.6 channel switch makes the binary the sole install path. ## What ships per release Seven targets as GitHub Release assets, plus matching ``.sha256`` checksum files: - ``x86_64-unknown-linux-gnu`` (glibc) - ``x86_64-unknown-linux-musl`` (static) - ``aarch64-unknown-linux-gnu`` (glibc, ARM server) - ``aarch64-unknown-linux-musl`` (static, ARM server) - ``x86_64-apple-darwin`` (Intel macOS, signed + notarized) - ``aarch64-apple-darwin`` (Apple Silicon, signed + notarized) - ``x86_64-pc-windows-msvc`` (Windows) Archives use the ``mergify-<tag>-<target>.tar.gz`` / ``.zip`` naming convention. Linux and Windows builds go through ``taiki-e/upload-rust-binary-action`` which handles cross-compilation via ``cross`` automatically. macOS builds run natively on Apple Silicon runners with an explicit pipeline because of the signing + notarization steps. ## macOS signing / notarization The macOS job imports a Developer ID Application certificate into a throwaway keychain, codesigns the binary with the hardened runtime + timestamp, then submits it to Apple's notarytool service. Stapling isn't possible on a bare Mach-O; online Gatekeeper checks approve notarized binaries on first run. Required GitHub Actions secrets (all six must be set before the next release): APPLE_CERTIFICATE base64 of the .p12 Developer ID cert APPLE_CERTIFICATE_PASSWORD password set when exporting the .p12 APPLE_SIGNING_IDENTITY "Developer ID Application: Mergify SAS (TEAMID)" APPLE_API_KEY base64 of the App Store Connect .p8 API key APPLE_API_KEY_ID 10-char key ID from App Store Connect APPLE_API_KEY_ISSUER issuer UUID from App Store Connect ## Install story today Users grab a binary from the releases page: ``https://github.com/Mergifyio/mergify-cli/releases/latest``. A ``curl | sh`` installer script + Homebrew tap land in separate follow-up PRs once we've seen the first binary release succeed. ## Parallel with PyPI ``release.yml`` (existing) keeps publishing to PyPI unchanged. Both workflows key off the same ``release: published`` event. The Phase 1.6 channel switch is the user-coordinated moment where we stop publishing to PyPI and direct users to the binary. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Change-Id: I48adf3e4ebfb49a1ea4ba171862ec72ba1776d7f
jd
force-pushed
the
devs/jd/worktree-rust-port/add-rust-release-workflow-targeting-github--48adf3e4
branch
from
cb257f5 to
44fc353
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Starts distributing the static Rust binary alongside the existing
PyPI wheel. Both pipelines run on every published GitHub Release
until the Phase 1.6 channel switch makes the binary the sole
install path.
What ships per release
Seven targets as GitHub Release assets, plus matching
.sha256checksum files:x86_64-unknown-linux-gnu(glibc)x86_64-unknown-linux-musl(static)aarch64-unknown-linux-gnu(glibc, ARM server)aarch64-unknown-linux-musl(static, ARM server)x86_64-apple-darwin(Intel macOS, signed + notarized)aarch64-apple-darwin(Apple Silicon, signed + notarized)x86_64-pc-windows-msvc(Windows)Archives use the
mergify-<tag>-<target>.tar.gz/.zipnaming convention. Linux and Windows builds go through
taiki-e/upload-rust-binary-actionwhich handlescross-compilation via
crossautomatically. macOS builds runnatively on Apple Silicon runners with an explicit pipeline
because of the signing + notarization steps.
macOS signing / notarization
The macOS job imports a Developer ID Application certificate into
a throwaway keychain, codesigns the binary with the hardened
runtime + timestamp, then submits it to Apple's notarytool
service. Stapling isn't possible on a bare Mach-O; online
Gatekeeper checks approve notarized binaries on first run.
Required GitHub Actions secrets (all six must be set before the
next release):
APPLE_CERTIFICATE base64 of the .p12 Developer ID cert
APPLE_CERTIFICATE_PASSWORD password set when exporting the .p12
APPLE_SIGNING_IDENTITY "Developer ID Application: Mergify SAS (TEAMID)"
APPLE_API_KEY base64 of the App Store Connect .p8 API key
APPLE_API_KEY_ID 10-char key ID from App Store Connect
APPLE_API_KEY_ISSUER issuer UUID from App Store Connect
Install story today
Users grab a binary from the releases page:
https://github.com/Mergifyio/mergify-cli/releases/latest.A
curl | shinstaller script + Homebrew tap land in separatefollow-up PRs once we've seen the first binary release succeed.
Parallel with PyPI
release.yml(existing) keeps publishing to PyPI unchanged.Both workflows key off the same
release: publishedevent.The Phase 1.6 channel switch is the user-coordinated moment where
we stop publishing to PyPI and direct users to the binary.
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
Depends-On: #1296