| Age | Commit message (Collapse) | Author |
|
https://github.com/ruby/ruby/actions/runs/14585602800/job/40910453142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
installed
https://github.com/rubygems/rubygems/commit/a087c452ad
|
|
This is how Ruby works, and it's not going to change. So let's run the
test since it makes no sense to keep it pending.
https://github.com/rubygems/rubygems/commit/5f78d3c737
|
|
https://github.com/rubygems/rubygems/commit/abb658757f
|
|
They had slightly different behavior in Bundler 2 and Bundler 3 because
Bundler 3 will auto-clean after `bundle install`, so one of them system
installed gems won't be present when `Bundler.setup` fails.
We can unify the specs by moving installing system gems to _after_
`bundle install`, so the behavior in both cases is the same. Also, only
this spec actually needs these gems installed, so we can move that from
the `before` block to the body of the spec.
https://github.com/rubygems/rubygems/commit/b7251ec9c6
|
|
to be conservative
When converging specification to pass the set of versions that should be
preserved from the lockfile during resolution, we should make sure all
top level gems are considered, and only exclude those gems themselves
(and not their dependencies) if their locked versions happen to not be
satisfied by an edited Gemfile.
https://github.com/rubygems/rubygems/commit/ed2f1b7b88
|
|
Due to a typo in the spec, the issue was not caught initially. If
Bundler does not need to re-resolve, `bundle lock` is a noop so Bundler
does not add checksums.
To fix the issue, we do something similar to what `bundle install` does,
just without actually installation. First set the domain (local or
remote) according to whether a re-resolve is necessary, and then
materialize lazy specifications into real specifications, so that
checksums are actually fetched from each source.
https://github.com/rubygems/rubygems/commit/84b6f4ee96
|
|
* bundler/lib/bundler/templates/newgem/README.md.tt (Development): Use the
test_task value to get the correct test task name ("test", not "test-unit").
* bundler/spec/commands/newgem_spec.rb (README.md): Add tests for test task
names for each test frameworks.
https://github.com/rubygems/rubygems/commit/2a24708a63
|
|
https://github.com/rubygems/rubygems/commit/e7f5f067e8
|
|
https://github.com/rubygems/rubygems/commit/1fc1e74f4d
|
|
https://github.com/rubygems/rubygems/commit/3f39571181
|
|
Signed-off-by: Andrew Nesbitt <andrewnez@gmail.com>
https://github.com/rubygems/rubygems/commit/897819da36
|
|
These are marked as realworld, but the realworld workflow file does not
install graphviz, so the specs are actually skipped.
These are not actually realworld, so remove that tag. Now they'll be run
together with the reset of specs in the standard workflow file, which
does install `graphviz`.
https://github.com/rubygems/rubygems/commit/e865fcaa22
|
|
checksums in fresh lockfiles
https://github.com/rubygems/rubygems/commit/50b9ef8589
|
|
https://github.com/rubygems/rubygems/commit/506a863b36
|
|
existing lockfile
https://github.com/rubygems/rubygems/commit/0a9c1ce60d
|
|
After having a second look at this deprecation, the explanation that
we're giving does not make a lot of sense. When working only with local
gems, Bundler will indeed generate a different lockfile depending on
the latest installed version of each gem is at `bundle install` time.
That's the same situation that happens with remote sources: Bundler will
generate a different lockfile depending on the latest version of each
gem available remotely.
So, I don't think "a consistent lockfile not getting generated" is a
good motivation for deprecating this.
Also, this deprecation brings additional challenges, since for example,
it should arguably not get printed when using `bundle install --local`?
The original problem when this deprecation was introduced was an
incorrect message about a missing gem having been yanked.
So, I think a better solution is to, as long as we give proper error
messages when things go wrong, let users do what's best for them and
undo the deprecation.
https://github.com/rubygems/rubygems/commit/17499cb83f
|
|
https://github.com/rubygems/rubygems/commit/d478ec403f
|
|
extension from source
https://github.com/rubygems/rubygems/commit/9b0ec807c7
|
|
installation path with bad permissions
https://github.com/rubygems/rubygems/commit/07e7f0bf5e
|
|
It gives better errors.
https://github.com/rubygems/rubygems/commit/bedae080ef
|
|
https://github.com/rubygems/rubygems/commit/71fd896041
|
|
exec` context
https://github.com/rubygems/rubygems/commit/ad95a1dfaa
|
|
https://github.com/rubygems/rubygems/commit/9548aa6766
|
|
https://github.com/rubygems/rubygems/commit/f4d31c0a97
|
|
This option is similar to the `bundle install --quiet` option
https://github.com/rubygems/rubygems/commit/3bd773d827
|
|
compatible requirements
https://github.com/rubygems/rubygems/commit/a8d14c1fc2
|
|
wrong source
https://github.com/rubygems/rubygems/commit/1e5780db0a
Co-authored-by: Taylor Thurlow <thurlow@hey.com>
|
|
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
https://github.com/rubygems/rubygems/commit/d8b5d05e46
|
|
Signed-off-by: Samuel Giddins <segiddins@segiddins.me>
https://github.com/rubygems/rubygems/commit/06eec6d855
|
|
It was printing incorrect output and returning incorrect status.
https://github.com/rubygems/rubygems/commit/96f5979c7d
|
|
https://github.com/rubygems/rubygems/commit/362c960497
|
|
Nothing here relies on the dependency being on a pre-release, and
Bundler does not use prereleases in the realworld.
https://github.com/rubygems/rubygems/commit/96f5742ff1
|
|
https://github.com/rubygems/rubygems/commit/3434f094a2
|
|
https://github.com/rubygems/rubygems/commit/edbb2e3475
|
|
They are used by default.
https://github.com/rubygems/rubygems/commit/0b7f7d879f
|
|
As long as we use a high enough test version, the default version of
Bundler should never get in the middle.
https://github.com/rubygems/rubygems/commit/d63f0818aa
|
|
https://github.com/rubygems/rubygems/commit/d850ea1d95
|
|
This was commented out almost 10 years ago, but I think it passes now!
https://github.com/rubygems/rubygems/commit/4a6b1aba3c
|
|
Currently, an exe file isn't executable when generating new gems
because it doesn't have the correct permission.
This PR sets the correct permission same as files under the `bin`.
https://github.com/rubygems/rubygems/commit/6509bf128a
|
|
Ruby ships with empty directories for default gems. If Ruby
installations has unsafe world-writable permissions, we will complain
when about to install a gem that happens to be also a default gem,
because we'll start by removing the previous install folder and that's
supposed to be insecure due to too loose permissions.
However, if the folder is empty, we don't actually need to remove
anything, so we can skip the whole thing, avoiding the errors.
https://github.com/rubygems/rubygems/commit/2f3cd8ac4e
|
|
https://github.com/rubygems/rubygems/commit/7c71dac22e
|
|
`bundle outdated`
Before, `bundle outdated --parseable` (or `--porcelain`) caused output
to be completely silenced during definition resolution, so nothing was
printed at all until the table of outdated gems was printed.
With this change, `--parseable`/`--porcelain` now prints progress to
stderr during resolution. E.g.:
```
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
```
This provides a better user experience, especially when
`outdated --parseable` takes several seconds or more.
The report of outdated gems is still printed to stdout, and the exit
status codes are unchanged, so the fundamental contract with other tools
consuming the `outdated --parseable` result should not be affected.
https://github.com/rubygems/rubygems/commit/7d4bb43570
|