build(deps): take the checkout bump, and stop the two that cannot land - #10
Merged
Merged
Conversation
This was referenced Aug 25, 2026
Dependabot opened two updates that CI rejected, for different reasons. `windows` 0.61.3 -> 0.62.2 cannot land at all: tauri-runtime's WindowBuilder trait takes windows::Win32::Foundation::HWND in owner() and parent(), and tauri-runtime 2.11.3 — the newest release — requires ^0.61. Bumping ours alone puts two semver-incompatible `windows` in the graph, so the HWND in the impl is a different type from the HWND in the trait and the build fails with E0053. The version moves when tauri-runtime moves, so ignore minor and major bumps on it and say why in Cargo.toml. Patch updates inside 0.61 still resolve to one copy and are left open. dtolnay/rust-toolchain 1.95.0 -> 1.100.0 fails earlier still: the refs on that action are Rust versions, and it carries branches for versions rustup cannot install yet — 1.99.0 and 1.100.0 are both there while stable is 1.98.0 — so the highest ref installs nothing and every build job dies on a 404 from static.rust-lang.org. The version is rust-toolchain.toml's call regardless, and the action takes it at the call site rather than reading that file, so the pin is bumped by hand alongside it and Dependabot is told to leave it alone. That leaves actions/checkout v4 -> v7, which is a real update and is taken here. The v7 break is fork checkouts under pull_request_target and workflow_run; nothing here uses either trigger.
jonathanKingston
force-pushed
the
claude/dep-updates-failures-736424
branch
from
August 25, 2026 01:33
1f6add7 to
63bd760
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.
Resolves the two red Dependabot PRs, #8 and #5. They fail for unrelated reasons, and only one of the three updates in them is actually takeable.
windows0.61.3 → 0.62.2 (#8) — cannot landtauri-runtime'sWindowBuildertrait takeswindows::Win32::Foundation::HWNDinowner()andparent(), andtauri-runtime2.11.3 (the newest release) requires^0.61. Bumping our copy alone puts two semver-incompatiblewindowsin the graph, so theHWNDin our impl is a different type from the one in the trait:The version is not ours to choose — it moves when
tauri-runtimemoves. Minor and major bumps are now ignored, with the reason recorded next to the dependency inCargo.toml. Patch updates inside 0.61 still resolve to a single copy, so those stay open.dtolnay/rust-toolchain1.95.0 → 1.100.0 (#5) — cannot landThat action's refs are Rust versions, and the repository carries branches for versions rustup cannot install yet:
1.99.0and1.100.0both exist there while stable is 1.98.0. So the numerically highest ref installs nothing, and all three build jobs died in under a minute:Which toolchain CI installs is
rust-toolchain.toml's call anyway, and the action takes the version at the call site rather than reading that file (toolchainis a required input), so the pin is bumped by hand alongside it. Dependabot is told to leave it alone.actions/checkoutv4 → v7 (#5) — takenThe real update, and the only one kept. The v7 break is fork checkouts under
pull_request_targetandworkflow_run; nothing here uses either trigger. It is already proven green — under #5 thefmtandpatch series appliesjobs passed on v7, and all three build jobs got past checkout before failing on the toolchain step.Once this lands, Dependabot retires #8 and #5 on its next weekly run; closing them now just avoids leaving two red PRs open until then.