ruby.git/spec, branch master

[ruby/rubygems] Gracefully handle missing checksums in Compact Index

2026-05-14T05:59:58+00:00

https://github.com/ruby/rubygems/commit/234e2b7d5f

[ruby/rubygems] Skip git source exclusion when lockfile cannot backfill

2026-05-14T05:34:22+00:00

The git source exclusion in `find_source_requirements` introduced by
ruby/rubygems#9234 relies on `locked_requirements` to backfill the gap
for sources used only by --without groups. Without a Gemfile.lock —
e.g. an initial `BUNDLE_ONLY=ci bundle install` where a default-group
gem from a git source is shifted into the "excluded" set — that
fallback is absent, and the source's indirect dependencies fall
through to the default rubygems source, causing resolution to fail.

Gate the exclusion on `nothing_changed?` so it only applies when the
lockfile is guaranteed to cover the excluded sources.

Fix ruby/rubygems#9536

https://github.com/ruby/rubygems/commit/89ed2bc9ef

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Allow File.writable?/File.readable? fallbacks in doctor specs

2026-05-14T01:37:59+00:00

doctor_spec.rb strict-stubs File.writable? and File.readable? with
specific paths, which was safe as long as the doctor command did
not trigger Plugin.hook. The new before-eval/after-eval hooks
fire during Bundler.definition, which the doctor command calls,
and Plugin.hook initializes Plugin::Index, which touches
Bundler.user_home and calls File.writable? on the test home path.
Those calls do not match the stubs and RSpec raises.

Match the existing File.exist? pattern and add and_call_original
fallbacks so unrelated paths fall through to the real methods,
while the specific stubs continue to control the paths under test.

https://github.com/ruby/rubygems/commit/a8c04c4536

Co-Authored-By: Claude Opus 4.6 (1M context)

[ruby/rubygems] Add specs for fetch and git fetch plugin hooks

2026-05-14T01:37:57+00:00

Covers the four new hook events added in the previous commit:
before-fetch, after-fetch, before-git-fetch, after-git-fetch.

https://github.com/ruby/rubygems/commit/a08ea29297

Co-Authored-By: Claude Opus 4.6 (1M context)

[ruby/rubygems] Add bundler before/after eval hooks for plugins

2026-05-14T01:37:56+00:00

https://github.com/ruby/rubygems/commit/fefe97c0bd

[Feature #21979] Allow negative offset in unpack

2026-05-11T04:54:09+00:00

[ruby/rubygems] Use optimistic version constraints in bundle gem output

2026-05-11T02:49:07+00:00

This changes the gemspec and Gemfile to use optimistic versions for
dependencies.

https://github.com/ruby/rubygems/commit/92b0305c8b

[ruby/rubygems] Allow non-zero exit status in bundle config gemfile unset spec

2026-05-08T09:31:54+00:00

After 607648d5fc9 (`bundle config get` exits 1 when the value is unset),
the spec added in 4658d6bd78b raises in the bundle helper because the
new test invokes `config get gemfile` after unsetting it.

Co-Authored-By: Claude Opus 4.7 (1M context)

[ruby/rubygems] Make `bundle config get` return status 1 when the value is not set

2026-05-08T08:08:04+00:00

Fix https://github.com/ruby/rubygems/pull/3215

Change the exit status to 1 when trying to `get` a config key that does not exist, as shown below.

```sh
$ bundle config get foo

Settings for `foo` in order of priority. The top value will be used

You have not configured a value for `foo`

$ echo $?
1
```

It seems that showing “Settings for `foo` in order of priority. The top value will be used” when the key does not exist is not very meaningful, but for now I have left the behavior unchanged except for the exit status.

In the tests, some existing cases try to `get` a missing config without `raise_on_error: false`, so set the value in advance or add `raise_on_error: false` to handle them.

https://github.com/ruby/rubygems/commit/73205e3d64

[ruby/rubygems] Honor LazySpec overrides in SpecSet#complete_platform

2026-05-08T06:43:48+00:00

complete_platform validates platform-specific candidates returned by
spec.source.specs.search, which are remote specs that do not carry
the override list. Borrow the override list from the LazySpec exemplar
already in scope so platform-variant validation uses the same effective
metadata as the install/resolve path.

Also propagate the overrides onto the synthesized LazySpec built from
platform_spec. Without this, the next complete_platform call could
pick the synthesized variant as its exemplar (it is now in the set
returned by lookup) and fall back to strict matching, dropping
platforms that the user's override would otherwise allow.

https://github.com/ruby/rubygems/commit/205955c5b3

Co-Authored-By: Claude Opus 4.7 (1M context)