RUBY_TEST_TIMEOUT_SCALE is set for debug builds because they are slower
to run. We should respect this environment variable in MMTk tests too.
https://github.com/ruby/mmtk/commit/0a66c518bf
The `ids` array and `dsymbol_fstr_hash` were pinned because they were
kept alive by rb_vm_register_global_object. This prevented the GC from
moving them even though there were reference updating code.
This commit changes it to be marked movable by marking it as a root object.
assert_handshake_error is useful for checking handshake failures
triggered by the peer, as the underlying socket may be closed
prematurely, leading to different exceptions depending on the platform
and timing.
However, when the local end aborts a handshake, the only possible
exception is OpenSSL::SSL::SSLError. Use stricter assertions in such
cases.
https://github.com/ruby/openssl/commit/637ba65818
The list of NPN protocols is validated in SSLContext#setup.
The assert_handshake_error is misleading. The client is unable to start
a handshake at all because the server is not running.
https://github.com/ruby/openssl/commit/e8db6ffd9e
Use start_server instead of start_server_version.
start_server_version is a wrapper around start_server that forces the
server to a specific protocol version using the now-deprecated method
SSLSocket#ssl_version=, but it does more than that. The slightly
different method signature and default values are confusing. Let's
use start_server directly.
https://github.com/ruby/openssl/commit/22ed31d77e
The default timeout on GitHub Actions is 360 minutes, the job usually takes
around 20 to 30 minutes to complete. This commit sets the timeout to be
40 minutes so jobs that hang will timeout faster.
I think we need this to silence the following warning when running
`bin/console` with Ruby 3.4
```
./bin/console:10: warning: irb was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add irb to your Gemfile or gemspec to silence this warning.
```
https://github.com/rubygems/rubygems/commit/c46230c856
For installed specifications, we can ignore any constraints they may
have, since we know they match the current version of Ruby or otherwise
would not be installed.
For remote specifications, we already resolve optimistically without
metadata and retry force-fetching it if necessary.
If in the future we support resolving against a Ruby version different
that the one being run, we'll probably need to change this but now it's
unnecessary and saves some memory.
### Before
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
### After
Total allocated: 259.89 MB (3134199 objects)
Total retained: 115.05 MB (1283779 objects)
https://github.com/rubygems/rubygems/commit/201c1863fc
They use less memory that way.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
### After
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
https://github.com/rubygems/rubygems/commit/a4ef9c5f56
Sometimes we'll resolve using bare `Gem::Dependency` instances rather
than `Bundler::Dependency` instances, which is fine, simpler, and saves
some memory.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 277.48 MB (3384318 objects)
Total retained: 117.53 MB (1338657 objects)
### After
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
https://github.com/rubygems/rubygems/commit/c6dc2966c5
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
### After
Total allocated: 277.44 MB (3383182 objects)
Total retained: 117.55 MB (1338622 objects)
https://github.com/rubygems/rubygems/commit/2d3d6e5015
Since not every dependency gets referenced.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 295.01 MB (3624335 objects)
Total retained: 119.31 MB (1364474 objects)
### After
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
https://github.com/rubygems/rubygems/commit/61eee39d81
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
Currently evenn if the require actually fails, they suggest that the
file was actually loaded, which is confusing. I reworded them to reduce
this confusion.
@peterzhu2118 mentioned that "View workflow run" button is broken in Launchable. It's because invalid URL is sent from compilers/actions.yaml. Launchable CLI builds URL based on the environment variables. In those variables, GITHUB_SERVER_URL is not set in this case.
Hence, I set GITHUB_SERVER_URL in compilers/actions.yaml in this PR.
