test: add port-inventory guard to catch un-ported Python commands#1296
Conversation
|
This pull request is part of a Mergify stack:
|
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🟢 🤖 Continuous IntegrationWonderful, this rule succeeded.
🟢 👀 Review RequirementsWonderful, this rule succeeded.
🟢 Enforce conventional commitWonderful, this rule succeeded.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 ReviewsWonderful, this rule succeeded.
🟢 📕 PR descriptionWonderful, this rule succeeded.
|
b887a4a to
fddda52
Compare
Revision history
|
1bccca9 to
db76eee
Compare
fddda52 to
3390a13
Compare
3390a13 to
6c36176
Compare
6c36176 to
93047fd
Compare
93047fd to
e525b00
Compare
e525b00 to
cc28fea
Compare
6470fc5 to
a286dbf
Compare
cc28fea to
2521caa
Compare
There was a problem hiding this comment.
Pull request overview
Adds a CI guardrail to keep the Python Click CLI command surface area in sync with the ongoing Rust port by introducing a repository-wide command inventory and a pytest that compares discovered Click commands against that inventory.
Changes:
- Add
PORT_STATUS.tomlat repo root to inventory all Click leaf subcommands withstatus = "native"/status = "shimmed". - Add
mergify_cli/tests/test_port_status.pyto walk the Click command tree and assert the inventory is complete, non-stale, and well-formed.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
mergify_cli/tests/test_port_status.py |
Implements the Click-tree walk and assertions comparing discovered commands to PORT_STATUS.toml. |
PORT_STATUS.toml |
Defines the baseline inventory of current Click commands and their port status. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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
2521caa to
631557e
Compare
Merge Queue Status
This pull request spent 16 seconds in the queue, including 2 seconds running CI. Required conditions to merge
|
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> Depends-On: #1296
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.tomllists every click subcommand with an explicitstatusof eithernative(handled by Rust's dispatch) orshimmed(forwarded to Python by the py-shim crate).mergify_cli/tests/test_port_status.pywalksmergify_cli.cli.cliand fires four assertions:
statusvalue.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 validateisnativetoday (from Phase 1.3 in the same stack). The remaining29 are
shimmed— each subsequent port PR flips its entry fromshimmedtonativein the same commit that adds the Rustdispatch, keeping the file and the code in lockstep.
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com