Skip to content

merge queue: embarking main (c30b79b), #1373 and #1364 together#1377

Closed
mergify[bot] wants to merge 5 commits into
mainfrom
mergify/merge-queue/4bfb5b4032
Closed

merge queue: embarking main (c30b79b), #1373 and #1364 together#1377
mergify[bot] wants to merge 5 commits into
mainfrom
mergify/merge-queue/4bfb5b4032

Conversation

@mergify
Copy link
Copy Markdown
Contributor

@mergify mergify Bot commented May 6, 2026

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

Branch main (c30b79b), #1373 and #1364 are embarked together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #1364.
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: 9b4f0e5ac6cb7362896e6b40b2b5dc8798f41c5d
previous_failed_batches: []
pull_requests:
  - number: 1364
    scopes: []
scopes: []
...

jd and others added 5 commits May 6, 2026 12:56
The 2026.5.5.x release shipped a ``ci scopes-send`` regression
(fixed in #1356): the Rust port deserialized the response body via
``let _: serde_json::Value = client.post(...)`` while the Python
original ignored the body, and the Mergify endpoint returns an
empty body on success. ``Value`` still requires valid JSON, so the
Rust version surfaced ``parse response JSON: error decoding
response body`` to every user once it shipped. Test mocks used
``set_body_json(json!({}))`` instead of an empty body, so the bug
hid through unit tests too.

The fix is structural — split the HTTP client so callers pick
``post`` (parses) vs ``post_no_response`` (drops) up front — but
the bug class is broader than this one command. Capturing the
lessons in AGENTS.md so the next porter (human or assistant) walks
through them before opening a PR.

Three categories of pitfall, all observed during the port so far:

1. **HTTP response handling** — match the Python original. If
   Python ignores the response, Rust must use ``post_no_response``
   etc.; if Python parses, optional/nullable fields must be
   ``Option<T>`` + ``#[serde(default)]``.

2. **Test fixtures** — mirror the real server. ``ResponseTemplate``
   bodies must match what the endpoint actually returns; an empty
   body is not the same as ``json!({})``.

3. **UX parity with click** — char-counted validators use
   ``chars().count()`` (not ``len()``); confirmation prompts go to
   stderr; resolve all required state before prompting.

Audit of existing/in-flight ports against the checklist:

- ``config validate``, ``config simulate`` (main): match
- ``ci scopes-send`` (main): regressed, fix in #1356
- ``queue pause`` / ``unpause`` (#1352): match
- ``ci git-refs`` / ``queue-info`` (#1353): no HTTP, no risk

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Change-Id: I1fd9757e7f0213b0aeecbb6eb52b59e689cdf05a
Centralizes the `--token` / `--api-url` / `--repository` resolvers
into one module so every ported command (config simulate,
ci scopes-send, the queue commands that follow in this stack)
shares the same fallback behavior:

- ``resolve_token``: explicit → ``MERGIFY_TOKEN`` → ``GITHUB_TOKEN``
  → ``gh auth token`` (subprocess; missing-binary or non-zero-exit
  is treated as "no token from gh", same as Python's
  ``CommandError`` catch in ``utils.get_default_token``).

- ``resolve_repository``: explicit → ``GITHUB_REPOSITORY`` →
  ``git config --get remote.origin.url`` parsed via ``parse_slug``
  (handles HTTPS and SSH shapes, strips ``.git`` and trailing
  slashes).

- ``resolve_api_url``: explicit → ``MERGIFY_API_URL`` →
  default ``https://api.mergify.com``.

The ``gh`` and ``git`` fallbacks are best-effort: missing binaries
or non-zero exits propagate as "fall through to the next source"
rather than surfacing errors. Mirrors the Python implementation.

``mergify-config::simulate`` and ``mergify-ci::scopes_send`` are
refactored in this same commit to use the new module — their
local copies of the resolvers (which were missing the gh / git
fallbacks) are removed. The duplicate tests that lived in those
modules are dropped; the env-precedence and slug-parsing coverage
now lives once in ``mergify_core::auth::tests``.

13 new tests in ``mergify_core::auth::tests``: env-var precedence
for token/api-url/repository, default API URL, error message
mentions ``gh client``, slug parsing for HTTPS / SSH / dot-git /
trailing-slash / empty-owner / path-without-repo. The
subprocess-fallback paths themselves aren't unit-tested (they
shell out to real binaries); the
``resolve_token_error_message_mentions_gh`` test exercises the
"PATH points to a directory with no gh" case to confirm the
fallback degrades cleanly.

The queue ports later in the stack consume this module from the
start — there's no transition period where they ship with a
private auth resolver.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Change-Id: I3ae3542b75bf407150b2607f50255ec91e9e9587
@mergify mergify Bot deployed to Mergify Merge Protections May 6, 2026 12:33 Active
@mergify mergify Bot temporarily deployed to func-tests-live May 6, 2026 12:33 Inactive
@mergify mergify Bot closed this May 6, 2026
@mergify mergify Bot deleted the mergify/merge-queue/4bfb5b4032 branch May 6, 2026 12:49
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