Bump rails from 16d8b82 to b9d6759 - #4
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [rails](https://github.com/rails/rails) from `16d8b82` to `b9d6759`. - [Release notes](https://github.com/rails/rails/releases) - [Commits](rails/rails@16d8b82...b9d6759) --- updated-dependencies: - dependency-name: rails dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
Author
|
Superseded by #5. |
jeremy
pushed a commit
that referenced
this pull request
Dec 16, 2025
Set MySQL max execution time of 5s
jeremy
added a commit
that referenced
this pull request
Aug 1, 2026
* Restore toolchain resolution in nested shells `git commit` from an agent session resolves the wrong ruby. The hook lints against system ruby 2.6.10 instead of the project's 3.4.10, and says nothing: it reports plausible paths throughout. Live on all five default branches since bcenv was retired, and what drove the `-n` bypass on bc3 master (d0edc1283b). `mise exec` does not prepend its tool directories unconditionally. When the shims directory is already on the inherited PATH it substitutes the install dirs at that entry's position, so inherited ordering -- not the hook -- decides the toolchain: shims ahead of /usr/bin installs land ahead project ruby /usr/bin ahead of shims installs land behind SYSTEM ruby shims absent entirely installs prepended project ruby A shipyard login shell puts shims first. An agent harness PATH puts /usr/bin at ~#12 and shims at ~#25. All five bin/rubocop are `#!/usr/bin/env ruby`, so the nested PATH picks the interpreter directly. bin/bcenv was immune because it re-derived PATH from the login profile rather than inheriting it; retiring it removed that protection. Arch is not affected -- shims #1, /usr/bin #4 in both login and non-login shells -- so this is macOS-agent-shell exposure today. The fix is ordering-independence, which is the property worth having everywhere. Pre-merge revisions carried exactly this fix and it was retired as unnecessary, on the finding that the broken ordering was "an artifact of a nested agent shell rather than a fleet condition". That premise is now false: shipyard provisions Claude Code, Codex and opencode on every machine, so the nested agent shell IS the fleet condition. Prepend rather than drop, decided on evidence. The retired code removed the shims entry, which works but needs canonical path comparison: a trailing-slash spelling defeats an exact-string filter and mise then behaves as if nothing was removed (measured: /usr/bin:$shims/:/bin resolves /usr/bin/ruby). That comparison was a ~20-line helper, itself refined twice for its own bugs. Prepending needs no equality logic and fixes every case that defeats dropping -- trailing slash, exact-but- late, shims absent, shims already first. The precedence chain mirrors mise's own, so a customised store is still honoured; checked against `mise doctor` for default storage, MISE_DATA_DIR, XDG_DATA_HOME, MISE_SHIMS_DIR, and overlapping overrides. The suite passed 14/14 against the broken hook, because neither existing scenario can reach the bug: the GUI one builds a shims-free PATH, and the terminal one harvests an already-ordered PATH from the login profile. So a third scenario models an agent session, ordering shims below /usr/bin. It forwards its own store variables rather than re-deriving them, because run_hook rebuilds the environment with `env -i` -- the same defect already found and fixed for the terminal scenario -- and carries __MISE_ORIG_PATH as a real agent session does. MISE_SHIMS_DIR joins the terminal harvest, since hook behaviour now depends on it. That scenario also asserts the resolved path, not just the version. A version comparison cannot detect this bug on Arch at all, where /usr/bin/ruby is also 3.4.10 and a broken hook passes. The assertion is scoped to the agent scenario deliberately: the expected path is derived in the invoking environment, so it names the invoking environment's store, while the GUI scenario deliberately receives no store variables and resolves the default one. Applying it globally would contradict the GUI model and fail a working hook -- reproduced with MISE_DATA_DIR pointed at an empty store, where the whole suite still passes, the agent scenario resolving out of that empty store and the other two out of the default one. Negative control run on both platforms: stripping only the prepend fails the agent scenario on macOS by version and by path, and on Arch by path alone. Verified end-to-end in a real agent shell, and confirmed inert where behaviour was already correct -- clean login shell and bare GUI environment unchanged on both platforms. * Forward MISE_INSTALLS_DIR to the agent scenario The new assertion compares an INSTALL path, and run_hook rebuilds the environment with `env -i`. Measured against `mise which ruby`, exactly two variables relocate the install tree: MISE_INSTALLS_DIR and MISE_DATA_DIR (XDG_DATA_HOME only through the latter's default). Only the second was forwarded, so under a MISE_INSTALLS_DIR override the probe resolved the default tree while expected_ruby_path named the custom one -- failing a working hook. Same defect already fixed for the terminal scenario, so it joins that harvest too. Reproduced with a populated custom install tree: without the forward the agent scenario fails 16/17, resolving ~/.local/share/mise/installs/ruby against an expected .../instdir/ruby; with it, 17/17. Found by Codex review. * Correct the stale premise in the header, and share one variable list The header recorded that shims handling was dropped because shipyard "already orders ~/.local/bin and mise's shims above /usr/bin, so `mise exec` resolves the toolchain unaided". That is the premise this branch overturns, so leaving it in place would have the file arguing against its own third scenario. It now states both halves: a login shell does order them that way, an agent session does not, and the new scenario is what holds that premise to account. The agent scenario also reuses $_mise_dirs rather than repeating it. The two lists existed for one reason -- name the mise configuration the expected values were derived from -- and the copy had already drifted once, which is precisely how the MISE_INSTALLS_DIR gap arose. * Fold the agent session into the header's list of ways git runs the hook The paragraph sat after "Run it directly: ./test/prek-hook-test", where "Git also runs it" read as the test rather than the hook. The header already enumerated the ways git runs the hook, so the agent session joins that list -- two ways becomes three -- and the correction of the stale premise follows it. * Record why the ground truth cannot be poisoned by the ordering under test expected_ruby and expected_ruby_path are derived in the invoking environment, which may itself be an agent shell with shims below /usr/bin -- so it looks like they could pick up the system ruby and report every scenario as failing. They cannot, and nothing in the file said why. The distinction is what mise is asked to resolve. `mise exec -- ruby` and `mise which ruby` name a TOOL, which mise resolves from its own registry. `mise exec -- <script>` only hands the script a PATH and lets the script resolve ruby itself; that is the hook's form, and how prek reaches bin/rubocop's `#!/usr/bin/env ruby`. Measured with a fake ruby placed first, ahead of both /usr/bin and the shims entry: the tool form returned 3.4.10, the script form ran the fake. Without the decoy, on the plain agent ordering: 3.4.10 and 2.6.10 respectively. Raised by Codex review; the finding does not hold, but the file was silent on it. * Forward MISE_SHARED_INSTALL_DIRS, and record the method that missed it mise honours MISE_SHARED_INSTALL_DIRS, so a store reachable only that way relocates the install tree too. run_hook's `env -i` dropped it, and the agent scenario asserts an install path -- so in a shared-store setup ground truth named the shared binary while the probe resolved, or auto-installed, a local copy, failing a working hook. The earlier revision asserted "exactly two variables relocate the install tree" and was measured wrongly: against a populated local store, which satisfies the lookup first and masks every fallback behind it. Re-measured against an empty local store, three do -- MISE_INSTALLS_DIR, MISE_SHARED_INSTALL_DIRS and MISE_DATA_DIR (XDG_DATA_HOME only through the latter's default) -- while MISE_SHIMS_DIR, MISE_STATE_DIR, XDG_STATE_HOME, MISE_CACHE_DIR, MISE_CONFIG_DIR and MISE_DOWNLOADS_DIR do not. Two things keep that method honest, and the comment now names both. A made-up variable name must leave `mise which ruby` unresolved, or the probe is measuring nothing. And mise distinguishes "Setting [x] is not set" from "Unknown setting: x"; only the second means mise does not read it. Reading the first as the second is what produced the wrong claim. Control, in a shared-store-only configuration (empty local store, empty config dir so no global tools are dragged in): without the forward the agent scenario fails 16/17, expected $shared/ruby/3.4.10/bin/ruby against a locally installed copy; with it, 17/17 resolving the shared path. The passing run has to start from a pristine store, or it passes off the local copy the failing run created -- the same masking again. Found by Codex review, twice: raised, wrongly rebutted here, re-raised with the flaw in my method named exactly. * State the honest limit of the forwarded-variable list The list is bounded by measurement, not enumerated from mise, and the comment now says so. `mise settings --all` does not report the path settings at all -- not data_dir, not installs_dir, not shared_install_dirs -- so there is no authoritative set to copy, and a variable nobody thought to probe would be missed the same way MISE_SHARED_INSTALL_DIRS was. Worth stating rather than implying completeness, because two rounds of review found holes in it. What bounds the damage is the direction of the failure: the assertion compares the hook's resolution against mise's own, so a missing variable makes the two disagree and this scenario fail under a store override. It cannot turn into a false pass.
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
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.
Bumps rails from
16d8b82tob9d6759.Commits
b9d6759Style pass over active_record/associations/builder/association.rbf0f624b[RF-DOCS] Action View Form Helpers Guide [ci-skip] (#51936)6045f25Merge pull request #52132 from skipkayhil/hm-rm-logger-predicates564e427Remove obsolete Logger severity predicates292c127Merge pull request #47713 from JuanVqz/railties/thor-stats-taskfca2a5eMerge pull request #51733 from seanpdoyle/document-yield-head004ab15Merge pull request #52215 from p8/railties/document-action-mailer-perform-cac...a1259c7Merge pull request #52220 from jcbages/patch-18a45223Merge pull request #52224 from Earlopain/rake-rdoc-abort999df68Merge pull request #52197 from heka1024/cache-controler-immutableDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)