Skip to content

[pull] master from ruby:master - #1384

Merged
pull[bot] merged 17 commits into
turkdevops:masterfrom
ruby:master
Sep 7, 2026
Merged

[pull] master from ruby:master#1384
pull[bot] merged 17 commits into
turkdevops:masterfrom
ruby:master

Conversation

@pull

@pull pull Bot commented Sep 7, 2026

Copy link
Copy Markdown

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 : )

OughtPuts and others added 17 commits September 6, 2026 23:25
… and info

ruby/rubygems@e25a58ade8

Co-authored-by: Harriet Oughton <harriet.oughton@shopify.com>
Co-authored-by: Jenny Shen <jenny.shen@shopify.com>
ruby/rubygems@57fc2d41b9

Co-authored-by: Gira Chawda <gira.chawda@shopify.com>
Co-authored-by: Jenny Shen <jenny.shen@shopify.com>
…ockfile, and local cache

ruby/rubygems@9c4afde89d

Co-authored-by: Jenny Shen <jenny.shen@shopify.com>
Gem::Indexer (rubygems-generate_index) loads the V1-only CompactIndex
constants, either from the compact_index gem or from its own embedded
copy, so the artifice's copy of rubygems.org's V2-only implementation
can never share that name safely.

Check in a copy of rubygems.org's lib/compact_index, renamed to the
VendoredCompactIndex namespace, under spec/support/vendor/compact_index,
and load it from the artifice with a plain require. Checking the copy in
(rather than downloading it during the test run) keeps the suite
hermetic and offline, makes the namespace rewrite visible in review, and
lets parallel workers and CI runners that skip the test-deps setup load
it without falling back to the incompatible gem.

Refresh the copy with `rake vendor:compact_index`;
`rake vendor:compact_index_check` fails if the checked-in copy drifts
from the pinned upstream ref.

ruby/rubygems@2ae5f05f52
…S lockfile section

A content-addressable gem was locked inline as name (version-address)
platform. Bundler 4.0 parses the token after the version as the platform,
gets unknown, materializes name-version-unknown, and fails: it then either
re-resolves and rewrites the lockfile or fails outright under frozen.
Lockfiles are committed and read by many Bundler versions during
co-publication, so the inline form breaks the exact clients the transition
is supposed to protect.

The spec line is now an ordinary platform pin, and the content address moves
to its own section:

    GEM
      specs:
        nokogiri (1.19.4-x86_64-linux)

    CONTENT ADDRESSES
      nokogiri (1.19.4-x86_64-linux) 86e5e59f sha256=<content-addressable build's sha>

    CHECKSUMS
      nokogiri (1.19.4-x86_64-linux) sha256=<platform build's sha>

Verified against the released Bundler 4.0.9:

- unknown unindented sections set @parse_method = nil and are skipped
  silently (lockfile_parser.rb:137)
- Definition#lockfiles_equal? subtracts unknown sections before comparing
  (definition.rb:1196), so a plain 4.0 bundle install does not rewrite the
  lockfile and the section survives; it is only dropped on a genuine 4.0
  re-lock, and restored on the next 4.1 re-lock
- 4.0 classifies a locked spec with a missing or empty CHECKSUMS entry as a
  lockfile change (definition.rb:619-620): a plain install re-resolves and
  frozen mode hard-fails. The platform lock name line must therefore carry a
  real checksum, and it must be the platform build's, since 4.0 attributes
  it to the artifact it installs for that lock name

That last point drives the checksum rules:

- the checksum store is keyed by full name instead of lock name, because a
  content-addressable build and the platform build of the same name,
  version, and platform share a lock name while being different files.
  Store#register accepts anything responding to full_name and lock_name, so
  the parser registers CHECKSUMS entries under the name tuple parsed from
  the line rather than the (possibly content-addressed) spec object
- the content-addressable build's checksum is serialized next to its
  address in CONTENT ADDRESSES, the only place older Bundler never parses,
  and verifies the downloaded gem via the existing install-time registration
- CHECKSUMS carries the platform build's checksum, which the compact index
  supplies for every row the fetcher sees, so it is captured during
  resolution without downloading the platform gem
- when no platform build exists (skinny-only publication), the CHECKSUMS
  line is omitted entirely rather than written bare, so every CHECKSUMS
  line describes an artifact installable by its lock name

The section registers in SECTIONS_BY_VERSION_INTRODUCED under 4.1.0, and
its line format requires a platform, since content addressing only applies
to platformed gems.

ruby/rubygems@7bf773ba05
…ntAddress and route every eligibility, naming, lockfile, plugin directory, and spec construction decision through its shared predicates

ruby/rubygems@a8ac2ed87f
@pull pull Bot locked and limited conversation to collaborators Sep 7, 2026
@pull pull Bot added the ⤵️ pull label Sep 7, 2026
@pull
pull Bot merged commit 7a095da into turkdevops:master Sep 7, 2026
0 of 2 checks passed
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.

3 participants