Skip to content

merge queue: embarking main (7fff439) and #1297 together#1317

Closed
mergify[bot] wants to merge 3 commits intomainfrom
mergify/merge-queue/2558ad7ce9
Closed

merge queue: embarking main (7fff439) and #1297 together#1317
mergify[bot] wants to merge 3 commits intomainfrom
mergify/merge-queue/2558ad7ce9

Conversation

@mergify
Copy link
Copy Markdown
Contributor

@mergify mergify Bot commented Apr 29, 2026

🎉 This pull request has been checked successfully and will be merged soon. 🎉

Branch main (7fff439) and #1297 are embarked together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #1297.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: 7fff43982fb73cb510823b88268b847263bb86ab
previous_failed_batches: []
pull_requests:
  - number: 1297
    scopes: []
scopes: []
...

jd and others added 3 commits April 29, 2026 11:06
During the Rust port, any new click command added to the Python CLI
risks being silently missed if the Rust dispatch isn't updated in
parallel. This adds a CI-enforced inventory at the repo root plus
a pytest that walks the click tree and compares against it.

## How it works

``PORT_STATUS.toml`` lists every click subcommand with an explicit
``status`` of either ``native`` (handled by Rust's dispatch) or
``shimmed`` (forwarded to Python by the py-shim crate).
``mergify_cli/tests/test_port_status.py`` walks ``mergify_cli.cli.cli``
and fires four assertions:

- Every discovered click command has an entry.
- Every entry corresponds to a live click command (no stale rows).
- Every entry uses a valid ``status`` value.
- No entry carries extra keys (catches typos like ``stats``).

Forgetting to update the file when adding a new Python command
becomes a CI failure at test-time rather than a "why is this
missing from the binary?" bug report months later.

## Current baseline

All 30 click subcommands are listed. Only ``config validate`` is
``native`` today (from Phase 1.3 in the same stack). The remaining
29 are ``shimmed`` — each subsequent port PR flips its entry from
``shimmed`` to ``native`` in the same commit that adds the Rust
dispatch, keeping the file and the code in lockstep.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Change-Id: I4a71d672f4795dbb3e2e9523ea01b8d7fbbfbcbe
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
@mergify mergify Bot deployed to Mergify Merge Protections April 29, 2026 12:56 Active
@mergify mergify Bot closed this Apr 29, 2026
@mergify mergify Bot deleted the mergify/merge-queue/2558ad7ce9 branch April 29, 2026 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant