Feat: LOGSTASH_PATH auto expanding

[kares]

this is mostly to be able to publish LS plugins, a Gemfile usually looks like:

logstash_path = ENV["LOGSTASH_PATH"] || "../../logstash"
use_logstash_source = ENV["LOGSTASH_SOURCE"] && ENV["LOGSTASH_SOURCE"].to_s == "1"

if Dir.exist?(logstash_path) && use_logstash_source
  gem 'logstash-core', :path => "#{logstash_path}/logstash-core"
  gem 'logstash-core-plugin-api', :path => "#{logstash_path}/logstash-core-plugin-api"
end

plugins usually depend on logstash-core and/or logstash-code-plugin-api gems
plugin-api hasn't been released in a while and possible logstash-core releases will halt as well

publish command adds --env "LOGSTASH_SOURCE=1 LOGSTASH_PATH=#{releases[last]}" defaults
where LOGSTASH_PATH='#{latest}' is tracked and #(enclosed) value gets substituted based on LS' release information (one could also override a specific version with LOGSTASH_PATH='#{7.5.1}')

the brackets #{...} part (#(...) also works - did not figure out anything more suitable) causes a LS release tar.gz download and gems extraction into a temp dir to substitute a valid LOGSTASH_PATH=...

[kares]

should have noted that both @jarvis publish ... and the new @jarvis run ... rake release
where tested manually (using --env "LOGSTASH_SOURCE=1 LOGSTASH_PATH=#{latest}" for run cmd)

[yaauie]

Functionality makes sense. I have left comments about potentially making the usage more clear.

[yaauie]

I think that the injection of ruby-style string interpolation into a shell command is likely to cause confusion, may require shell escaping on certain shells, and is likely more heavy-handed than we need.

Could we special-case LOGSTASH_PATH values starting with RELEASE@? This would make usage a bit more straight-forward and eliminate some of the complexity of shell-escaping values when using it:

• [email protected]
• LOGSTASH_PATH=RELEASE@latest
• [email protected]

With the above, we could also support SNAPSHOT@ prefixes for situations where we rely on a fix that hasn't made it into a release.

[kares]

thanks @yaauie ... struggled with the 'auto-expanding' naming convention.
very glad you looked into it - will look into changing the format as suggested.

[kares]

updated to use the suggested RELEASE/SNAPSHOT@ qualifier ...