Skip to content

[pull] master from ruby:master#882

Merged
pull[bot] merged 17 commits intoturkdevops:masterfrom
ruby:master
Mar 25, 2026
Merged

[pull] master from ruby:master#882
pull[bot] merged 17 commits intoturkdevops:masterfrom
ruby:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Mar 25, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

godfat and others added 17 commits March 25, 2026 02:41
When we run `bundle exec` it'll look at `Bundler.settings[:gemfile]`
and respect the Gemfile setting. However, when we just require
`bundler/setup` or run `Bundle.setup`, it'll not look through that.

This should make this behaviour consistent.

More details can be found at:
https://gitlab.com/gitlab-org/gitlab/-/issues/339939#note_667461354

ruby/rubygems@5e6333108b
…ile setting

The test was only checking that `bundle install` works with a custom
gemfile, but the purpose of this PR is to make `Bundler.setup` respect
the setting too. Updated the test to actually invoke Bundler.setup and
verify it loads gems from the custom gemfile.

ruby/rubygems@f3d6a16680

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

ruby/rubygems@bc40cc6ef6
- bundle update test: use gem.repo2 to match the before block's source
  and drop unnecessary myrack-obama dependency
- bundle info test: use rails which is already installed by the before
  block instead of myrack which was not installed

ruby/rubygems@128a94c9cb

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Remove jruby_only tag since the issue is not JRuby-specific
- Fix outdated output regex to match current format
- Remove duplicate fixnum patchlevel test since patchlevel
  checking is entirely removed

ruby/rubygems@a60329b8ad

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Remove the autobuild step and build-related setup steps since CodeQL
now supports scanning C/C++ without builds.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The condition `github.event_name == 'push' && github.event.pull_request.user.login == 'dependabot[bot]'`
was always false because `github.event.pull_request` does not exist
on push events. Simply checking `github.event.pull_request.user.login`
is sufficient as it naturally evaluates to false on non-PR events.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Dependabot Cargo updates directly affect YJIT/ZJIT builds, so these
workflows should run for Cargo dependency PRs. Other dependabot PRs
(GitHub Actions, Vcpkg) are skipped.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Vcpkg updates affect Windows build dependencies, so windows.yml and
mingw.yml should run for Vcpkg dependency PRs.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
On MinGW (Windows), pipe readiness after syswrite may not be
immediately visible to IO.select with timeout 0, causing a
spurious nil return. Retry with a longer timeout to handle this.

https://github.com/ruby/ruby/actions/runs/23519269557/job/68458831324?pr=16262
test_multiple_servers_with_timeout_and_truncated_tcp_fallback
(ruby/resolv#125)

The test uses intentionally tight timeouts to trigger TCP fallback, but
0.1s/0.2s can be too tight on loaded CI machines, causing the overall
test to time out before the fallback to server2 completes.

ruby/resolv@8984b87f57
…3.3:

- Disclaimer: I honestly wasn't able to understand the problem and why
  this solution works. I don't have a windows machine and relying on
  CI machines is a bit painful.

  When introducing ruby/rubygems#9414,
  master CI started to fail only on windows 3.3.
  I confirmed that running the failing spec in isolation multiple
  times reproduce the problem consistently.

  The error being either a segfault or a Bundler error along the line
  of "Illformed requirement `~> false.1.3.pre`".

  I triggered some CI with debugging output and the corruption
  seem to happen when `version.release` is called. It somehow
  modifies the previously defined variable `segments` (it's not
  a mutation).

  This is the debugging output I added Shopify/rubygems@6a147a0
  and the associated CI run is at https://github.com/Shopify/rubygems/actions/runs/23465022092/job/68275229509#step:7:177

  Pasting here in case the CI log get cleared:

  ```
    segments variable is [0, 12, 3, "pre"]. Object ID is 25820
    version.segments is [0, 12, 3, "pre"].
    ========
    AFTER
    ========
    Segments is [-1, 12, 3, "pre"]. Object ID is 25820
    version.segments is [0, 12, 3, "pre"].
  ```

  In this patch, I opted to reference the `version.segments` object
  directly, again, I don't know why it fixes the issue.

ruby/rubygems@532c9733aa
… values

nil is a valid value for default_cli_command since it represents an
unset configuration, which triggers a deprecation warning in CLI.

ruby/rubygems@0ecbfad4bd

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bumps the github-actions group with 1 update in the / directory: [taiki-e/install-action](https://github.com/taiki-e/install-action).


Updates `taiki-e/install-action` from 2.69.7 to 2.69.9
- [Release notes](https://github.com/taiki-e/install-action/releases)
- [Changelog](https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md)
- [Commits](taiki-e/install-action@0d865d5...328a871)

---
updated-dependencies:
- dependency-name: taiki-e/install-action
  dependency-version: 2.69.9
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: github-actions
...

Signed-off-by: dependabot[bot] <support@github.com>
@pull pull bot locked and limited conversation to collaborators Mar 25, 2026
@pull pull bot added the ⤵️ pull label Mar 25, 2026
@pull pull bot merged commit f045c1a into turkdevops:master Mar 25, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants