chore: remove mtgish importer - #7556
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (90)
💤 Files with no reviewable changes (63)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe dormant ChangesMTGISH importer removal
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to The PR removes the mtgish importer and its associated data and tests; no actionable merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Generated for head Parse changes introduced by this PR✓ No card-parse changes detected. |
…rs#7588) `chore: remove mtgish importer (phase-rs#7556)` deleted `crates/mtgish-import`, whose `serde_with = "3"` was the sole consumer of a 22-package subtree (schemars, darling, chrono, bs58, hex, windows-*, and a second indexmap). The regenerated root lockfile was never committed, so `cargo metadata --locked` fails on main and any cargo invocation rewrites Cargo.lock in place. That is what breaks Nightly Release. `cargo release --execute` refuses to run against a dirty tree: error: uncommitted changes detected, please resolve before release: Cargo.lock (Status(WT_MODIFIED)) Nightly last succeeded 2026-08-19 09:47Z, hours before phase-rs#7556 merged that evening, and has failed every night since. Pure pruning, no version changes: 22 [[package]] blocks removed, and every addition is an `"indexmap"` dependency line losing its version qualifier now that a single indexmap version remains. Verified by regenerating in a clean worktree at origin/main -- byte-identical result, and `cargo metadata --locked` passes afterwards. CI did not catch this because `--locked` is used only for the Tauri manifest (ci.yml:680,687), never for the root workspace. Claude-Session: https://claude.ai/code/session_01DJgbxMGnPi6MFfGUe15Y3P Co-authored-by: matthewevans <matthewevans@users.noreply.github.com>
`--locked` on the existing workspace clippy invocation costs no extra CI time --
that step already resolves the whole workspace -- and turns silent lockfile drift
into a fast, explicit failure.
Without it, removing a crate leaves its dependency subtree stranded in
Cargo.lock, every later cargo invocation rewrites the file in place, and CI stays
green because no root-workspace command passed `--locked`. Nightly Release is
where it surfaces, because `cargo release --execute` aborts on a dirty tree:
error: uncommitted changes detected, please resolve before release:
Cargo.lock (Status(WT_MODIFIED))
That is exactly how phase-rs#7556 (remove mtgish importer) broke three consecutive
nightlies before phase-rs#7588 resynced the lock. `--locked` was already used for the
Tauri manifest; this extends the same guarantee to the root workspace.
Verified both directions against origin/main in an isolated worktree: with the
pre-phase-rs#7588 lockfile the guarded command exits 101 in under two seconds on
"cannot update the lock file ... because --locked was passed", before compiling
anything; with the current lockfile it clears resolution and proceeds to compile
normally.
Claude-Session: https://claude.ai/code/session_01DJgbxMGnPi6MFfGUe15Y3P
Co-authored-by: matthewevans <matthewevans@users.noreply.github.com>
Summary by CodeRabbit
Documentation
Maintenance
Testing