-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Remove duplicate gems when producting logstash artifacts #18340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
1ba776c
6688f94
5093ae9
41d7795
c897246
129b0d9
5a3b2bb
334a244
0b9123d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -101,18 +101,6 @@ namespace "artifact" do | |
| @exclude_paths << 'vendor/**/gems/**/Gemfile.lock' | ||
| @exclude_paths << 'vendor/**/gems/**/Gemfile' | ||
|
|
||
| @exclude_paths << 'vendor/jruby/lib/ruby/gems/shared/gems/rake-*' | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are no longer required as they are handled by the new |
||
| # exclude ruby-maven-libs 3.3.9 jars until JRuby ships with >= 3.8.9 | ||
| @exclude_paths << 'vendor/bundle/jruby/**/gems/ruby-maven-libs-3.3.9/**/*' | ||
|
|
||
| # remove this after JRuby includes rexml 3.3.x | ||
| @exclude_paths << 'vendor/jruby/lib/ruby/gems/shared/gems/rexml-3.2.5/**/*' | ||
| @exclude_paths << 'vendor/jruby/lib/ruby/gems/shared/specifications/rexml-3.2.5.gemspec' | ||
|
|
||
| # remove this after JRuby includes net-imap-0.2.4+ | ||
| @exclude_paths << 'vendor/jruby/lib/ruby/gems/shared/specifications/net-imap-0.2.3.gemspec' | ||
| @exclude_paths << 'vendor/jruby/lib/ruby/gems/shared/gems/net-imap-0.2.3/**/*' | ||
|
|
||
| # Exclude env2yaml source files - only compiled classes should be in tarball | ||
| @exclude_paths << 'docker/data/logstash/env2yaml/**/*.java' | ||
| @exclude_paths << 'docker/data/logstash/env2yaml/build.gradle' | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -279,7 +279,11 @@ tasks.register("installCustomJRuby", Copy) { | |
| dependsOn buildCustomJRuby | ||
| description = "Install custom built JRuby in the vendor directory" | ||
| inputs.file(customJRubyTar) | ||
| outputs.dir("${projectDir}/vendor/jruby") | ||
| // Don't re-extract if core JRuby is already installed. This works around | ||
| // gem deduplication when rake calls back in to gradle. | ||
| onlyIf { | ||
| !file("${projectDir}/vendor/jruby/bin/jruby").exists() | ||
| } | ||
| from tarTree(customJRubyTar == "" ? jrubyTarPath : customJRubyTar) | ||
| eachFile { f -> | ||
| f.path = f.path.replaceFirst("^jruby-${customJRubyVersion}", '') | ||
|
|
@@ -294,7 +298,11 @@ tasks.register("downloadAndInstallJRuby", Copy) { | |
| dependsOn=[verifyFile, installCustomJRuby] | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. COREREVIEW: why is there a dep on |
||
| description = "Install JRuby in the vendor directory" | ||
| inputs.file(jrubyTarPath) | ||
| outputs.dir("${projectDir}/vendor/jruby") | ||
| // Don't re-extract if core JRuby is already installed. This works around | ||
| // gem deduplication when rake calls back in to gradle. | ||
| onlyIf { | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the interplay between gradle/rake it is hard (IMO impossible) to define a sane dependency graph to ensure that gems are cleaned after jruby has been installed and bundler has been run. TO get around issues where gradle was being tricked in to thinking we need a fresh jruby install when gems have been cleaned up, only install jruby when the executable is not in the expected place. This is kind of a hack as i could see a workflow where this would cause an issue with an unexpectedly old or broken jruby but I cant think of a way around it without majorly refactoring how our gradle/rake tasks are organized. |
||
| !file("${projectDir}/vendor/jruby/bin/jruby").exists() | ||
| } | ||
| from tarTree(downloadJRuby.dest) | ||
| eachFile { f -> | ||
| f.path = f.path.replaceFirst("^jruby-${jRubyVersion}", '') | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
@jsvd this is a good summary of what I found out today after our conversation.
More context on this particular change...
I was debugging the following faiures:
Which all failed with a message similar to:
Clearly indicating an issue with they pysch stdlib gemspec removal. I was very curious why this was not an issue in artifacts prepared with the gem cleanup. After investigating our complex set of manipulations of
GEM_HOMEandGEM_PATHacross cli entrypoints and tests I finally just started printing outLOAD_PATH. In a container, when we do something like alogstash-plugin updatewe get aLOAD_PATHat execution time like:For that same bit in the ruby unit tests we get a LOAD_PATH like:
As you can see the bundler
setup!adds the full bundled gem env to the load path BEFORE stdlib.Open questions/thoughts
LOAD_PATHis at various times in logstash execution (i've been focused mainly on the pluginmanager because that is where the test failures are).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.
Some additional testing affirms my initial observations. Essentially this boils down to the fact that
logstash-plugindoes not actually callLogStash::Boostrap#setup!in practice. So by invoking that directly before all unit tests we get a state that is inconsistent with the gem env in logstash run from artifacts. I'm tempted to try to localize this LOAD_PATH manipulation to just the tests where there are issues as there were only two test files where this was an issue and the majority of tests cover cases where thesetup!method would have been invoked.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.
Note that i did do some testing where for example pipeline code would use yaml/psych:
This did not result in any psych loading issues like the ones we saw in the unit tests. Similarly I printed the load path from a ruby filter context and it matched that of a result of calling the
setup!method.