Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
ci: workaround recent bundler release bug
I *think* this is related to: - rubygems/rubygems#5871 - (proposed fix) rubygems/rubygems#5875
- Loading branch information
b2adf01
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have this slowness on alpine for already like three years. Any host OS (macOS, Ubuntu, RHEL), different versions of Ruby, any cloud provider.
Finally got to the lldb and found it's doing some versions parsing billions of times (for example, the last method on stack was
canonical_segments
, the it's returning value below) and it's doing it for just a single commandgem install -N bundler:2.4.22
that was itself supposed to fix the issue if there is any in the gem that is in default docker image. But it takes eternity. Why does it parse anything at all if it's just a single gem install command with a specified version? It's doing it right after downloading the specs.gz.It is so weird I have this issue every time, for years. It was a pain for hobby projects but now it's on the way in my job.
Looks like it parses the versions of all the gems on rubygems, why?...
And I write here , because it's
for me, not the one in the commit.
b2adf01
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The example backtrace:
UPD:
even with flag
--ignore-dependencies
it's still doing it:I see the double nested this:
UPD2:
as I understand it goes to
add_always
before even looking at the install flag, and goes on with some dependencies resolving. Which is for some reason slow.UPD3: looks like with the flag
--ignore-dependencies
the attribute@ignore_dependencies
infind_all
isfalse
while the value istrue
during the options parsing. Is it being later overriden somewhere?b2adf01
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Nakilon Why are you commenting on a two-year old commit in an unrelated code base with information about an issue that should be filed upstream against rubygems?