Age | Commit message (Collapse) | Author |
|
The `RUBY_CODESIGN` environment variable is used by mkmf-generated
Makefile to sign extension bundles on macOS. The variable specifies a
key identifier to use for signing given by the user. However, the key
is usually stored in `$HOME/Library/Keychains` directory, and the test
suite creates a fake `$HOME` directory. This causes the test suite to
try to find the specified key from the fake home directory, which
results in a failure.
https://github.com/rubygems/rubygems/commit/ddcfc65bf7
|
|
https://github.com/rubygems/rubygems/commit/af806b8dff
|
|
|
|
Specs that use extension gems were failing in the new job but I noticed
that they were using very non standard `extconf.rb` files.
The hack being removed here was added just to make specs pass when run
in ruby-core but it seems the underlying issue has been fixed now, and
it's causing issues with Ruby 3.3 and Windows, so necessary so I'm
removing it and moving on.
https://github.com/rubygems/rubygems/commit/5b78275f0e
|
|
This seems worse to detect performance regressions, but at least should
not have many false positives.
https://github.com/rubygems/rubygems/commit/0b28e55415
|
|
Some specs assert empty output, but sometimes they print warnings about
redefinition warnings. Ignore those until they are fixed upstream.
https://github.com/rubygems/rubygems/commit/0cd3b6dbae
|
|
|
|
https://github.com/rubygems/rubygems/commit/d728fa1b04
|
|
request
https://github.com/rubygems/rubygems/commit/d26bcd7551
|
|
|
|
|
|
|
|
|
|
|
|
This makes bundler consistent with all other gems, and makes the default
installation of Bundler in the release package look like any other
bundler installation.
Before (on preview3, for example), Bundler executable is installed at:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/libexec/bundle
Now it's installed in the standard location:
lib/ruby/gems/3.3.0+0/gems/bundler-2.5.0.dev/exe/bundle
|
|
https://github.com/rubygems/rubygems/commit/0d758e8926
|
|
`BUNDLER_IGNORE_DEFAULT_GEM` set
https://github.com/rubygems/rubygems/commit/111bd11c36
|
|
And make it easier to update next time.
https://github.com/rubygems/rubygems/commit/1ea4bfa5d8
|
|
https://github.com/rubygems/rubygems/commit/55281f0eaa
|
|
rubygems-generate_index gem
So generate_index can be implemented with dependencies, such as the compact index
Took this approach from feedback in https://github.com/rubygems/rubygems/pull/6853
Running `gem generate_index` by default will use an installed rubygems-generate_index, or install and then use the command from the gem
Apply suggestions from code review
https://github.com/rubygems/rubygems/commit/fc1cb9bc9e
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
|
|
https://github.com/rubygems/rubygems/commit/bb66253f2c
|
|
Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.
https://github.com/rubygems/rubygems/commit/2353cc93a4
|
|
This changes the CompactIndexClient to store etags received from the
compact index in separate files rather than relying on the MD5 checksum
of the file as the etag.
Smoothes the upgrade from md5 etags to opaque by generating them when no
etag file exists. This should reduce the initial impact of changing the
caching behavior by reducing cache misses when the MD5 etag is the same.
Eventually, the MD5 behavior should be retired and the etag should be
considered completely opaque with no assumption that MD5 would match.
|
|
https://github.com/rubygems/rubygems/commit/ed4eaefac0
|
|
Gem::RemoteFetcher uses Gem::Request, which adds the RubyGems UA.
Gem::RemoteFetcher is used to download gems, as well as the full index.
We would like the bundler UA to be used whenever bundler is making
requests.
This PR also avoids unsafely mutating the headers hash on the shared
`Gem::RemoteFetcher.fetcher` instance, which could cause corruption or
incorrect headers when making parallel requests. Instead, we create one
remote fetcher per rubygems remote, which is similar to the connection
segregation bundler is already doing
https://github.com/rubygems/rubygems/commit/f0e8dacdec
|
|
https://github.com/rubygems/rubygems/commit/70243b1d72
|
|
https://github.com/rubygems/rubygems/commit/93619c97ff
|
|
Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.
There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.
This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.
With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.
https://github.com/rubygems/rubygems/commit/5f24f06bc5
|
|
https://github.com/rubygems/rubygems/commit/7ab4c203f9
|
|
in Bundler specs
We want to avoid any "user home" fallbacks, since that won't work with
Bundler.
So if there's a permissions issue during specs, it's best to raise
immediately.
https://github.com/rubygems/rubygems/commit/767a3e7533
|
|
https://github.com/rubygems/rubygems/commit/2eb2860e9e
|
|
compatibility.
Save checksums using = as separator.
https://github.com/rubygems/rubygems/commit/a36ad7d160
|
|
Improve error reporting for checksums, raises a new error class.
Solve for multi-source checksum errors.
Add CHECKSUMS to tool/bundler/(dev|standard|rubocop)26_gems.rb
https://github.com/rubygems/rubygems/commit/26ceee0e76
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
|
|
code.
(https://github.com/rubygems/rubygems/pull/6917)
https://github.com/rubygems/rubygems/commit/2238bdaadc
|
|
This gets the specs passing, and handles the fact that we expect
checkums to be pinned only to a particular source
This also avoids reading in .gem files during lockfile generation,
instead allowing us to query the source for each resolved gem to grab
the checksum
Finally, this opens up a route to having user-stored checksum databases,
similar to how other package managers do this!
Add checksums to dev lockfiles
Handle full name conflicts from different original_platforms when adding checksums to store from compact index
Specs passing on Bundler 3
https://github.com/rubygems/rubygems/commit/86c7084e1c
|
|
if possible
1. Use the checksum provided by the server if provided: provides security
knowing if the gem you downloaded matches the gem on the server
2. Calculate the checksum from the gem on disk: provides security knowing
if the gem has changed between installs
3. In some cases, neither is possible in which case we don't put anything
in the checksum and we maintain functionality as it is today
Add the checksums to specs in the index if we already have them
Prior to checksums, we didn't lose any information when overwriting specs
in the index with stubs. But now when we overwrite EndpointSpecifications
or RemoteSpecifications with more generic specs, we could lose checksum
info. This manually sets checksum info so we keep it in the index.
https://github.com/rubygems/rubygems/commit/de00a4f153
|
|
We lock the checksum for each resolved spec under a new CHECKSUMS
section in the lockfile.
If the locked spec does not resolve for the local platform, we preserve
the locked checksum, similar to how we preserve specs.
Checksum locking only makes sense on install. The compact index
information is only available then.
https://github.com/rubygems/rubygems/commit/bde37ca6bf
|
|
https://github.com/rubygems/rubygems/commit/64e7a2656a
|
|
https://github.com/rubygems/rubygems/commit/d275cdccb1
|
|
https://github.com/rubygems/rubygems/commit/ffa395411f
|
|
https://github.com/rubygems/rubygems/commit/d0c1d97105
|
|
https://github.com/rubygems/rubygems/commit/d2f2597c31
|
|
https://github.com/rubygems/rubygems/commit/ea2a30ba08
|
|
Pick from https://github.com/rubygems/rubygems/commit/880dd95996c93adc1e032399816931b243c5fe17
Notes:
Merged: https://github.com/ruby/ruby/pull/7961
|
|
https://github.com/rubygems/rubygems/commit/522b5f1ecd
|
|
https://github.com/rubygems/rubygems/commit/550d90f4ba
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7873
|
|
|
|
If Gemfile has a lot of dependencies, we have an optimization that uses
the full index in that case, assuming it's going to be faster.
I think this is an old optimization that predates compact index API
times, I believe we no longer need it these days.
Also, since a few releases ago we check for circular dependencies when
resolving by looping through all versions of each name and removing
those that have circular dependencies that would trip up the resolver.
This loop becomes actually very slow when full indexes are used because
to find dependencies of a gemspec, we need to explicitly fetch the
marshaled gemspec (`gemspec.rz` endpoint) for it, so the optimization
has the opposite effect of making things very slow.
https://github.com/rubygems/rubygems/commit/2f46289bd3
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/7582
|