Fix GEM_PATH regression in 1.13. #4992

chrismo · 2016-09-15T15:02:07Z

nth time is a charm ... here's the latest latest latest commit message:

Fix disable_shared_gems bug & keep nested exec
tl;dr --deployment will copy all gems to the --path now and a
proper fix is in place for nested bundle execs when --path is set and
RubyGems >=2.6.2 is being used.

Fixes #4974.

There's two problems blended in here. Let's trace the events here from
the beginning, shall we?

First off, from probably the first versions of Bundler, when
disable_shared_gems is true, the GEM_PATH gets internally overridden
and initialized to an empty string. This is done to make sure that later
in the Bundler.setup process it's expanded to ONLY the Bundler --path
setting, otherwise it expands to include the system path.

In 1.12, bundle exec was changed to use Kernel.load in some cases,
and that new code path calls require "bundler/setup".

Later, issue #4592 was filed, showing that in cases like --deployment
where disable_shared_gems is true, Bundler couldn't find itself,
because Bundler never lives in the --path but only in system gems. And
as it would later be discovered, was not a problem with RubyGems 2.6.1,
but was a problem with >=2.6.2 (and older RubyGems it would seem, though
those weren't as thoroughly investigated).

We fixed #4592 (see PR #4701) in 1.13.0 by changing the oooold code
initializing GEM_PATH to be initialized to nil instead of empty
string in all disable_shared_gems cases. But it created another bug,
filed as #4974, wherein system gems were no longer copied to the
--path when disable_shared_gems is true. In this commit here (#4992)
we've reverted the change so that GEM_PATH is now back to being
initialized to an empty string instead of nil.

That fixes #4974, but regresses #4592, and we needed a new way to fix
it.

After a few tortured attempts at this, I ran across issue #4602, a
similar report of nested bundle execs being broken, #4602 itself an
extension of #4381 reporting the same problem. It brought to light the
role the Rubygems version played in the problem.

When the bundler gem is installed and the wrapper is generated for any
gem executables, the contents of this wrapper are determined by the
Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper
calls Gem.bin_path. Bundler replaces the Rubygems implementation of
Gem.bin_path with its own, and has for a long time made a special
exception for the Bundler gem itself, short-circuiting with the contents
of a special ENV variable called BUNDLE_BIN_PATH.

In Rubygems 2.6.2, bin_path was superseded by a new
Gem.activate_bin_path method which did what bin_path did but also
activated the gem. Bundler 1.13 added support for this, but it didn't
include the same short-circuit for bundler itself. (Alert user @taoza
even noticed this here
fcaab35#r56665282).

This commit also includes that short circuit for Rubygems >=2.6.2 now
and nested bundle exec should continue to work.

segiddins

looks good, but we definitely need test coverage for this

segiddins · 2016-09-16T09:51:10Z

lib/bundler/cli/exec.rb

@@ -81,6 +82,38 @@ def kernel_load(file, *args)
      abort "#{e.class}: #{e.message}\n  #{backtrace.join("\n  ")}"
    end

+    # This is pretty damned esoteric. Since the dawn of Bundler, when


please remove the damned

Yes, sorry - it was late at night.

segiddins · 2016-09-16T10:18:32Z

lib/bundler/cli/exec.rb

+    # the weirdness right here, with this method and its appropriate
+    # 27-to-1 ratio of doc lines to code lines.
+    def fixup_gem_path_env
+      ENV['GEM_PATH'] = nil if Bundler.settings[:disable_shared_gems]


double quotes

Yeah, I forgot to run rubocop, though I knew this wasn't done yet - no tests.

chrismo · 2016-09-16T15:02:11Z

yeah, tests for the bundle exec, and tests for the disable_shared_gems putting all gems into the --path, which said tests would have prevented this change in the first place.

indirect · 2016-09-16T17:59:16Z

@chrismo awesomeeeeee thank you for tracking this down 🙇 I'm very excited to get this fixed once we have tests. :)

chrismo · 2016-09-16T18:47:02Z

due credit to @miros for isolating the problem commit in #4974 in the first place

chrismo · 2016-09-18T20:09:21Z

The comments were a bit rambly and late-night stream of consciousness. Re-wrote them to try and be clearer (and committed the bug unfixed at the moment whilest I still work out tests).

Still need to research bundle exec tests -- there's actually plenty of coverage in spec/install/path_spec.rb, I don't know why CI continues to pass those specs when locally they clearly fail for me when the bug is in play.

segiddins · 2016-09-19T06:54:39Z

lib/bundler.rb

+        # this needs to be empty string to cause
+        # PathSupport.split_gem_path to only load up the
+        # Bundler --path setting as the GEM_PATH.
+        env["GEM_PATH"] = ''


double quotes

chrismo · 2016-09-20T05:37:37Z

This isn't working. I still can't get any spec within the bundler codebase itself to reliably recreate the problem, because it's a nested bundle exec that is the original problem ... and that's just a bit too bizarre for my brain to figure out.

The spec_helper calls Spec::Rubygems.setup which sets up the PATH to be:

  ENV["PATH"] = ["#{Path.root}/exe", "#{Path.system_gem_path}/bin", ENV["PATH"]].join(File::PATH_SEPARATOR)

placing the local exe/bundle in the PATH, thwarting any attempt to recreate a nested bundle exec accurately which IRL needs to be hitting the Rubygems generated bin entry:

#!/usr/bin/env ruby
#
# This file was generated by RubyGems.
#
# The application 'bundler' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'
# ...snip...
load Gem.activate_bin_path('bundle', 'bundle', version)

So. I at least created this bundler-case based on the original #4592 bug report. This accurately shows the nested bundle exec problem in 1.12.5 and the fix in 1.13.1.

But the code HERE in this PR (#4992) - while it fixes #4974, it regresses the nested bundle exec fix (#4592).

The reason is also due to the nature of the 1.12.5 change to use Kernel.load (same process) instead of Kernel.exec (a new process). There's so much global state (and a lot of it memoized) that's setup in require "bundler/setup" -- I can't find a way to create a workaround to fix up the pathing. It gets easily as complicated as the above situation just trying to recreate a failing spec. (Very happy to be wrong here, btw).

So so.

IMO, #4974 is a much worse problem than #4592. #4974 keeps --deployment from working properly (unless none of your bundled gems are installed as system gems). #4592 only breaks nested bundle exec only in a --path install situation.

I'd rather release a 1.13.2 with #4974 fixed and intentionally regress #4592 until we can figure out how to properly support the nested bundle exec case.

chrismo · 2016-09-21T15:14:56Z

proactive code review - I'm being a little sloppy on this PR, I'll rebase and remove the version change that snuck in and everything before for realz. Just pushing for comment on the substantive parts.

segiddins · 2016-09-21T15:44:17Z

lib/bundler/cli/exec.rb

+    def configure_gem_path_override
+      if Bundler.settings[:disable_shared_gems]
+        # TODO MODO hate this spooky at a distance global state voodoo
+        ENV["DO_NOT_LIMIT_GEM_PATH"] = "true"


any reason this couldn't just check if ENV["GEM_PATH"].nil?

this configure_gem_path_override method is now called before require "bundler/setup" ... prior commit had me attempting to undo something that was done inside bundler/setup after it was called ... had to change the approach since it was too late at that point.

segiddins · 2016-09-21T15:44:58Z

spec/commands/exec_spec.rb

+      bundle :install, :system_bundler => true, :path => "vendor/bundler"
+    end
+
+    it "works with disable_shared_gems" do


needs a more descriptive name

Samuel contributed this patch to simulate a system bundler.

chrismo · 2016-09-21T22:13:32Z

Ok, I think this ready, presuming CI passes.

indirect · 2016-09-21T22:17:54Z

@segiddins all your requested changes appear to be addressed in the final commit, even though they're still shown in the PR... is that normal? this seems sub-optimal. :/

chrismo · 2016-09-21T22:28:30Z

dunno - prior versions of github, before the code review stuff, used to collapse comments on old commits. i'm not used to the new review flow ... maybe @segiddins needs to "sign off" on his comments in some way?

indirect · 2016-09-21T22:41:59Z

yeah, I guess so. well, I'm happy with this, so @homu r+.

chrismo · 2016-09-21T22:43:31Z

shoot. i also built a bundler-cases for this - and it's still failing. argh. looking ...

indirect · 2016-09-21T22:45:31Z

heh. well, in that case... @homu r-

indirect · 2016-09-21T22:46:16Z

@homu r=chrismo

@chrismo when you're ready, you can approve this for testing and merging with the comment r+ directed at homu. once that's done, I'd like to release 1.13.2.

homu · 2016-09-21T22:46:18Z

📌 Commit d08c778 has been approved by chrismo

…ismo Fix GEM_PATH regression in 1.13. This is a bit esoteric. There's two separate pieces to understand first. (1) When `:disable_shared_gems` is true, the `GEM_PATH` gets initialized to an empty string. This is done to make sure it's expanded to ONLY the Bundler --path setting, otherwise it expands to include the system path. (2) Prior to 1.12, the code here in bundle exec didn't use Kernel.load and didn't `require "bundler/setup"`, which meant the path to gems was never involved. In 1.12, bundle exec was overhauled for various reasons to use Kernel.load, and `require "bundler/setup"` is now invoked, which created a bug. In cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. We fixed this (the bundle exec bug) in 1.13.0 by changing GEM_PATH to be initialized to nil instead of empty string in all cases. But it created another bug. We've reverted the change so that GEM_PATH is now back to being initialized, but still need to patch up GEM_PATH right here to allow bundle exec to continue to work. Fix #4974 - [x] Needs tests

homu · 2016-09-21T22:46:29Z

⌛ Testing commit d08c778 with merge c9ece1c...

indirect · 2016-09-21T22:46:50Z

...dammit, I can't remember the bot's syntax.

@homu r-
@homu delegate=chrismo

homu · 2016-09-21T22:46:52Z

✌️ @chrismo can now approve this pull request

homu · 2016-09-22T00:01:06Z

💔 Test failed - status

@taoza

tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes rubygems#4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue rubygems#4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed rubygems#4592 (see PR rubygems#4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as rubygems#4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` is true. In this commit here (rubygems#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes rubygems#4974, but regresses rubygems#4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue rubygems#4602, a similar report of nested bundle execs being broken, rubygems#4602 itself an extension of rubygems#4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here rubygems@fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work. Thx to @miros for filing rubygems#4974 and isolating the problem in 1.12, @segiddins for many contributions and better ideas, and everyone else for their patience :)

chrismo · 2016-09-27T14:50:28Z

bah, keep forgetting that one test I'd added that's still failing. fixing, new commit shortly

@taoza

tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes rubygems#4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system gems path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue rubygems#4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed rubygems#4592 (see PR rubygems#4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as rubygems#4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` was true. In this commit here (rubygems#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes rubygems#4974, but regresses rubygems#4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue rubygems#4602, a similar report of nested bundle execs being broken, rubygems#4602 itself an extension of rubygems#4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here rubygems@fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work. Thx to @miros for filing rubygems#4974 and isolating the problem in 1.12, @segiddins for many contributions and better ideas, and everyone else for their bug reports and patience :)

chrismo · 2016-09-27T17:45:21Z

@homu retry

chrismo · 2016-09-27T17:45:47Z

@homu r+

homu · 2016-09-27T17:45:48Z

📌 Commit 4ab674f has been approved by chrismo

chrismo · 2016-09-27T18:02:12Z

@homu retry

indirect · 2016-09-27T18:49:49Z

ffffuuuu, sorry @chrismo

@homu retry

@taoza

…ismo Fix GEM_PATH regression in 1.13. _nth time is a charm ... here's the latest latest latest commit message_: Fix disable_shared_gems bug & keep nested exec tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes #4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue #4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed #4592 (see PR #4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as #4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` is true. In this commit here (#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes #4974, but regresses #4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue #4602, a similar report of nested bundle execs being broken, #4602 itself an extension of #4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work.

homu · 2016-09-27T19:02:56Z

⌛ Testing commit 4ab674f with merge 30a161e...

homu · 2016-09-27T20:54:29Z

☀️ Test successful - status

chrismo · 2016-09-27T21:07:06Z

whew. and don't come back :)

@taoza

…ismo Fix GEM_PATH regression in 1.13. _nth time is a charm ... here's the latest latest latest commit message_: Fix disable_shared_gems bug & keep nested exec tl;dr `--deployment` will copy _all_ gems to the `--path` now and a proper fix is in place for nested bundle execs when `--path` is set and RubyGems >=2.6.2 is being used. Fixes #4974. There's two problems blended in here. Let's trace the events here from the beginning, shall we? First off, from probably the first versions of Bundler, when `disable_shared_gems` is true, the `GEM_PATH` gets internally overridden and initialized to an empty string. This is done to make sure that later in the `Bundler.setup` process it's expanded to ONLY the Bundler `--path` setting, otherwise it expands to include the system path. In 1.12, `bundle exec` was changed to use `Kernel.load` in some cases, and that new code path calls `require "bundler/setup"`. Later, issue #4592 was filed, showing that in cases like `--deployment` where `disable_shared_gems` is true, Bundler couldn't find itself, because Bundler never lives in the `--path` but only in system gems. And as it would later be discovered, was not a problem with RubyGems 2.6.1, but was a problem with >=2.6.2 (and older RubyGems it would seem, though those weren't as thoroughly investigated). We fixed #4592 (see PR #4701) in 1.13.0 by changing the oooold code initializing `GEM_PATH` to be initialized to `nil` instead of empty string in all `disable_shared_gems` cases. But it created another bug, filed as #4974, wherein system gems were no longer copied to the `--path` when `disable_shared_gems` is true. In this commit here (#4992) we've reverted the change so that `GEM_PATH` is now back to being initialized to an empty string instead of `nil`. That fixes #4974, but regresses #4592, and we needed a new way to fix it. After a few tortured attempts at this, I ran across issue #4602, a similar report of nested bundle execs being broken, #4602 itself an extension of #4381 reporting the same problem. It brought to light the role the Rubygems version played in the problem. When the `bundler` gem is installed and the wrapper is generated for any gem executables, the contents of this wrapper are determined by the Rubygems version. Up until RubyGems 2.6.1 the last line of this wrapper calls `Gem.bin_path`. Bundler replaces the Rubygems implementation of `Gem.bin_path` with its own, and has for a long time made a special exception for the Bundler gem itself, short-circuiting with the contents of a special ENV variable called `BUNDLE_BIN_PATH`. In Rubygems 2.6.2, `bin_path` was superseded by a new `Gem.activate_bin_path` method which did what `bin_path` did but also activated the gem. Bundler 1.13 added support for this, but it didn't include the same short-circuit for bundler itself. (Alert user @taoza even noticed this here fcaab35#r56665282). This commit also includes that short circuit for Rubygems >=2.6.2 now and nested bundle exec should continue to work.

* 'master' of github.com:bundler/bundler: (163 commits) remove always-failing 1.8.7 build Rename to force_ruby_platform Fail fast in the specs when running from a path with special characters Change changelog on rubygems#4974 Version 1.13.2 with changelog Auto merge of rubygems#4990 - bundler:seg-realworld-flex, r=segiddins Auto merge of rubygems#4922 - JuanitoFatas:fix/4914-gemfile-engine-symbol-and-string, r=segiddins Auto merge of rubygems#4983 - bundler:seg-redefine-method-visibility, r=indirect Auto merge of rubygems#4994 - bundler:seg-definition-init-perf, r=segiddins Auto merge of rubygems#4971 - bundler:seg-pare-metadata-error, r=indirect Auto merge of rubygems#4998 - srbaker:patch-1, r=segiddins Auto merge of rubygems#4968 - bundler:seg-exec-load-docs, r=indirect Auto merge of rubygems#5002 - alepore:fix-colors, r=indirect Auto merge of rubygems#5015 - m1k3:fix-settings-no-config, r=segiddins Auto merge of rubygems#4992 - chrismo:fix_disable_shared_gems_gem_path, r=chrismo Auto merge of rubygems#5008 - bundler:seg-lazy-specification-materialize-platform, r=indirect Auto merge of rubygems#5014 - bundler:seg-auto-install-bool-key, r=indirect Auto merge of rubygems#4928 - bundler:seg-update-compact-index, r=segiddins Improve IRB behavior in generated bin/console Add a spec for only_ruby_platform ...

chrismo mentioned this pull request Sep 15, 2016

Regression in disable_shared_gems behavior #4974

Closed

segiddins suggested changes Sep 16, 2016

View reviewed changes

segiddins reviewed Sep 16, 2016

View reviewed changes

chrismo self-assigned this Sep 16, 2016

chrismo mentioned this pull request Sep 17, 2016

missing lots of gems in cache after 1.12.5->1.13.1 #4997

Closed

chrismo force-pushed the fix_disable_shared_gems_gem_path branch from 5b19c05 to 8f3dd8f Compare September 18, 2016 20:05

segiddins reviewed Sep 19, 2016

View reviewed changes

segiddins reviewed Sep 21, 2016

View reviewed changes

@segiddins support for system bundler

62c5319

Samuel contributed this patch to simulate a system bundler.

chrismo force-pushed the fix_disable_shared_gems_gem_path branch 2 times, most recently from 0482075 to d08c778 Compare September 21, 2016 22:12

This was referenced Sep 23, 2016

Nested bundle exec support is broken on latest rubygems/bundler combo #4602

Closed

[RubygemsIntegration] Add support for new activate_bin_path binstubs #4341

Merged

chrismo force-pushed the fix_disable_shared_gems_gem_path branch from 654f80b to db83b3c Compare September 27, 2016 05:46

chrismo force-pushed the fix_disable_shared_gems_gem_path branch from db83b3c to 4ab674f Compare September 27, 2016 15:09

chrismo mentioned this pull request Sep 27, 2016

Investigate why breaking --path in 4701 did not fail specs in CI. #5025

Closed

homu merged commit 4ab674f into rubygems:master Sep 27, 2016

segiddins added this to the 1.13 - Release 1.13.2 milestone Sep 27, 2016

coilysiren modified the milestones: 1.13 - Release 1.13.2, 1.13 - Patch 1.13.2 Oct 3, 2016

javan mentioned this pull request Jan 11, 2018

Breaking bundle exec rails/webpacker#1150

Closed

Fix GEM_PATH regression in 1.13. #4992

Fix GEM_PATH regression in 1.13. #4992

Conversation

chrismo commented Sep 15, 2016 • edited Loading

segiddins left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrismo commented Sep 16, 2016

indirect commented Sep 16, 2016

chrismo commented Sep 16, 2016

chrismo commented Sep 18, 2016 • edited Loading

Choose a reason for hiding this comment

chrismo commented Sep 20, 2016 • edited Loading

chrismo commented Sep 21, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chrismo commented Sep 21, 2016

indirect commented Sep 21, 2016

chrismo commented Sep 21, 2016

indirect commented Sep 21, 2016

chrismo commented Sep 21, 2016

indirect commented Sep 21, 2016

indirect commented Sep 21, 2016

homu commented Sep 21, 2016

homu commented Sep 21, 2016

indirect commented Sep 21, 2016

homu commented Sep 21, 2016

homu commented Sep 22, 2016

chrismo commented Sep 27, 2016

chrismo commented Sep 27, 2016

chrismo commented Sep 27, 2016

homu commented Sep 27, 2016

chrismo commented Sep 27, 2016

indirect commented Sep 27, 2016

homu commented Sep 27, 2016

homu commented Sep 27, 2016

chrismo commented Sep 27, 2016

chrismo commented Sep 15, 2016 •

edited

Loading

chrismo commented Sep 18, 2016 •

edited

Loading

chrismo commented Sep 20, 2016 •

edited

Loading