Bump rails from 16d8b82 to 4867559 - #13
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [rails](https://github.com/rails/rails) from `16d8b82` to `4867559`. - [Release notes](https://github.com/rails/rails/releases) - [Commits](rails/rails@16d8b82...4867559) --- 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 #14. |
jeremy
pushed a commit
that referenced
this pull request
Dec 16, 2025
jeremy
added a commit
that referenced
this pull request
Aug 1, 2026
…mise does Two follow-ups to the toolchain-resolution fix. Neither changes the hook's behaviour: its 43 executable lines are byte-identical to master. The agent scenario rebuilt its environment under `env -i` and forwarded a hand-maintained list of the MISE_* variables that can relocate mise's install tree -- expected_ruby_path is derived in the invoking environment, so any variable missing from that list made the two disagree and failed a working hook. The list fell behind twice (MISE_INSTALLS_DIR, then MISE_SHARED_INSTALL_DIRS), and it could not have been completed even in principle: shared_install_dirs is a real mise setting, so a config FILE relocates the install tree too, and the list named no config-dir variable at all. Measured -- with MISE_CONFIG_DIR pointing at a config declaring shared_install_dirs, the old harness fails a working hook and this one passes. So delete the list. run_hook_inheriting() inherits the invoking environment and overrides only PATH, __MISE_ORIG_PATH and PROBE_ENV_KEYS, which is what an agent session actually does; the two now agree by construction under any store configuration. The [env] keys are unset so those assertions cannot pass on ambient state from a mise-activated shell. Both files described `mise exec` as substituting install dirs at the shims entry's position. Measured on 2026.7.10 (the floor) and 2026.7.16, on macOS and Arch, mise strips the install directories it recognises out of the inherited PATH, then inserts the resolved ones immediately BEFORE the shims entry -- keeping that entry -- or prepends them when there is none. Which is why a globally activated installs/ruby/4/bin at PATH #13 still loses to /usr/bin/ruby at #22. Recorded in both files with the measured rewrites. Adds a decoy scenario: an unrelated ruby ahead of /usr/bin. Not a different mise code path -- /usr/bin/ruby is already foreign and never stripped -- but a deterministic competitor that does not depend on what ruby the platform ships, failing unmistakably as DECOY_RUBY. Adds an in-suite negative control. The agent and decoy scenarios run under two activation states (mise's session internals retained, and fully scrubbed), and a mutated hook with the two shims-prepend lines removed must resolve the wrong ruby. Green assertions prove nothing unless a broken hook turns them red, and this file has twice shipped assertions that could not fail. Failure to mutate is fatal rather than a skip.
jeremy
added a commit
that referenced
this pull request
Aug 1, 2026
…mise does Two follow-ups to the toolchain-resolution fix. Neither changes the hook's behaviour: its 43 executable lines are byte-identical to master. The agent scenario rebuilt its environment under `env -i` and forwarded a hand-maintained list of the MISE_* variables that can relocate mise's install tree -- expected_ruby_path is derived in the invoking environment, so any variable missing from that list made the two disagree and failed a working hook. The list fell behind twice (MISE_INSTALLS_DIR, then MISE_SHARED_INSTALL_DIRS), and it could not have been completed even in principle: shared_install_dirs is a real mise setting, so a config FILE relocates the install tree too, and the list named no config-dir variable at all. Measured -- with MISE_CONFIG_DIR pointing at a config declaring shared_install_dirs, the old harness fails a working hook and this one passes. So delete the list. run_hook_inheriting() inherits the invoking environment and overrides only PATH, __MISE_ORIG_PATH and PROBE_ENV_KEYS, which is what an agent session actually does; the two now agree by construction under any store configuration. The [env] keys are unset so those assertions cannot pass on ambient state from a mise-activated shell. Both files described `mise exec` as substituting install dirs at the shims entry's position. Measured on 2026.7.10 (the floor) and 2026.7.16, on macOS and Arch, mise strips the install directories it recognises out of the inherited PATH, then inserts the resolved ones immediately BEFORE the shims entry -- keeping that entry -- or prepends them when there is none. Which is why a globally activated installs/ruby/4/bin at PATH #13 still loses to /usr/bin/ruby at #22. Recorded in both files with the measured rewrites. Adds a decoy scenario: an unrelated ruby ahead of /usr/bin. Not a different mise code path -- /usr/bin/ruby is already foreign and never stripped -- but a deterministic competitor that does not depend on what ruby the platform ships, failing unmistakably as DECOY_RUBY. Adds an in-suite negative control. The agent and decoy scenarios run under two activation states (mise's session internals retained, and fully scrubbed), and a mutated hook with the two shims-prepend lines removed must resolve the decoy, asserted by exact path and version rather than merely differing from expected -- this file has twice shipped assertions that could not fail. Failure to mutate is fatal rather than a skip.
jeremy
added a commit
that referenced
this pull request
Aug 1, 2026
…mise does (#3016) Two follow-ups to the toolchain-resolution fix. Neither changes the hook's behaviour: its 43 executable lines are byte-identical to master. The agent scenario rebuilt its environment under `env -i` and forwarded a hand-maintained list of the MISE_* variables that can relocate mise's install tree -- expected_ruby_path is derived in the invoking environment, so any variable missing from that list made the two disagree and failed a working hook. The list fell behind twice (MISE_INSTALLS_DIR, then MISE_SHARED_INSTALL_DIRS), and it could not have been completed even in principle: shared_install_dirs is a real mise setting, so a config FILE relocates the install tree too, and the list named no config-dir variable at all. Measured -- with MISE_CONFIG_DIR pointing at a config declaring shared_install_dirs, the old harness fails a working hook and this one passes. So delete the list. run_hook_inheriting() inherits the invoking environment and overrides only PATH, __MISE_ORIG_PATH and PROBE_ENV_KEYS, which is what an agent session actually does; the two now agree by construction under any store configuration. The [env] keys are unset so those assertions cannot pass on ambient state from a mise-activated shell. Both files described `mise exec` as substituting install dirs at the shims entry's position. Measured on 2026.7.10 (the floor) and 2026.7.16, on macOS and Arch, mise strips the install directories it recognises out of the inherited PATH, then inserts the resolved ones immediately BEFORE the shims entry -- keeping that entry -- or prepends them when there is none. Which is why a globally activated installs/ruby/4/bin at PATH #13 still loses to /usr/bin/ruby at #22. Recorded in both files with the measured rewrites. Adds a decoy scenario: an unrelated ruby ahead of /usr/bin. Not a different mise code path -- /usr/bin/ruby is already foreign and never stripped -- but a deterministic competitor that does not depend on what ruby the platform ships, failing unmistakably as DECOY_RUBY. Adds an in-suite negative control. The agent and decoy scenarios run under two activation states (mise's session internals retained, and fully scrubbed), and a mutated hook with the two shims-prepend lines removed must resolve the decoy, asserted by exact path and version rather than merely differing from expected -- this file has twice shipped assertions that could not fail. Failure to mutate is fatal rather than a skip.
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
16d8b82to4867559.Commits
4867559Merge pull request #52084 from jhawthorn/time_with_zone_always_time36b2dbfMerge pull request #52271 from Schwad/schwad/only_watch_local_translations725ebc9Remove code for DateTime-backed TimeWithZone86d3ea1Merge pull request #52306 from fatkodima/fix-flaky-instrumentation-teste98f4d8Merge pull request #52305 from joshuay03/fix-52304182988bFix a flaky Active Record instrumentation test38c1d5a[Fix #52304] Avoid computingklassif reflection is abelongs_toin `Acti...e617046Do not watch translations from gems when reloading is enabled69d904eMerge pull request #49854 from skipkayhil/hm-document-aj-loggerac916c6Document ActiveJob::Base#logger and #log_argumentsDependabot 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)