uphold 1.5.0: one set, for a tool installed by hand rather than by a resolver - #62
Conversation
…resolver Minor. One bundled set is added and nothing existing changes shape: the fourteen sets a 1.4.x policy can name resolve to exactly the rules they resolved to before, and every top-level field is the field it was. THERE IS A REINSTALL REQUIREMENT, and it is the same one 1.4.0 had. A set ships compiled into the binary, so a policy naming `hand-rolled-toolchain` against a 1.4.x binary does not fall back or warn -- the set does not resolve, the policy fails to load, and a `git` or `gh` shim built on that policy fails closed. Bump the pin and reinstall in the same change, or do not name the set yet. No repository is affected until it names it. WHAT THE SET REFUSES. A host tool fetched and unpacked by hand where a version manager was available: no-hand-rolled-tool-install a fetch piped into an unpacker no-hand-rolled-tool-symlink an `ln -s` onto PATH out of $HOME/.local Promoted on a sweep that found the same Zig tarball installer written out in ten repositories -- same `uname -m` case, same two architectures, same ~/.local/zig, same `ln -sf` -- beside four further bespoke answers to the same question in one workspace. The cost is not the duplication: a hand-written installer is untested on the platform it will fail on, and the measured failures are all of that shape -- a `mv` into a ~/.local that does not exist yet on a fresh runner, and a vendor release with no Linux asset on the architecture nobody developed on. Both rules fire on a COMMAND rather than on a declaration. What the set deliberately leaves alone is argued in its header: `curl ... | sh`, because that is how a version manager itself arrives; a [[tool]] row or a `want`, because a resolver provisions and a doctor verifies and the two must be different programs; and distro packages, because refusing those pushes a repository toward vendoring by hand, which is this set's own failure arriving from the other side. `unmanaged-pins` does not already cover this and cannot: every one of the ten builds its URL out of shell variables, so there is no version in the line to match.
|
Warning Review limit reached
Next review available in: 34 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #62 +/- ##
=======================================
Coverage 89.81% 89.81%
=======================================
Files 32 32
Lines 10161 10161
=======================================
Hits 9126 9126
Misses 1035 1035 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2 participants
Minor. One bundled set is added and nothing existing changes shape: the fourteen sets a 1.4.x policy can name resolve to exactly the rules they resolved to before, and every top-level field is the field it was.
There is a reinstall requirement
Same one 1.4.0 had. A set ships compiled into the binary, so a policy naming
hand-rolled-toolchainagainst a 1.4.x binary does not fall back and does not warn: the set does not resolve, the policy fails to load, and agitorghshim built on that policy fails closed.Bump the pin and reinstall in the same change, or do not name the set yet. No repository is affected until it names it.
What the set refuses
no-hand-rolled-tool-installno-hand-rolled-tool-symlinkln -sonto PATH out of$HOME/.localMerged in #61, with the argument and the corpus. Promoted on a sweep that found the same Zig tarball installer written out in ten repositories (same
uname -mcase, same two architectures, same~/.local/zig, sameln -sf) beside four further bespoke answers to the same question in one workspace.Files bumped
Cargo.toml,Cargo.lock,README.md(3 refs),hooks/lefthook.yml(2 refs).Verified
495 tests pass, 0 fail. Full hook set clean.