This is a meta issue to track progress for refactoring the defaults plugins. Core plugins migration has been completed per #5170. Related #5140.
This migration recipe goals are:
feature/plugin-api-2_0logstash-plugins repo..travis.yml should be updated to
sudo: false
jdk:
- oraclejdk8
language: ruby
cache: bundler
rvm:
- jruby-1.7.25
before_install:
- git clone -b feature/event_interface https://github.com/elastic/logstash
script:
- bundle exec rspec spec
minimally these gems need to be added to the plugin Gemfile
# this is temporary for the feature/plugin-api-2_0 branch and is meant for travis testing
gem "logstash-core", :path => "./logstash/logstash-core"
gem "logstash-core-plugin-api", :path => "./logstash/logstash-core-plugin-api"
gem "logstash-core-event-java", :path => "./logstash/logstash-core-event-java"
gem "logstash-devutils", :github => "elastic/logstash-devutils", :branch => "feature/plugin-api-2_0"
add any other plugins in the gemspec required by this plugin, for example, if logstash-codec-plain is a required plugin add this:
gem "logstash-codec-plain", :github => "logstash-plugins/logstash-codec-plain", :branch => "feature/plugin-api-2_0"
modify the gemspec to bump the plugin-api version constrain to 2.0:
s.add_runtime_dependency "logstash-core-plugin-api", "~> 2.0"
and finally, refactor code and specs for new Event interface
if you want to test locally you will have to create a symbolic link to the logstash code base with the feature/event_interface shared branch
ln -s /you/path/to/logstash .
bundle
bundle exec rspec spec
@ph has added this ruby script to automate much of the initial work: https://gist.github.com/e28dddccfbe32c3985ab51d6f9b9ec41
We can automate all of the heavy work minus the actual code/spec?
Are we fine doing that?
@ph +1 for automating..
it might be tricky to automate the addition of dependent plugins from the gemspec but the basic block
# this is temporary for the feature/plugin-api-2_0 branch and is meant for travis testing
gem "logstash-core", :path => "./logstash/logstash-core"
gem "logstash-core-plugin-api", :path => "./logstash/logstash-core-plugin-api"
gem "logstash-core-event-java", :path => "./logstash/logstash-core-event-java"
gem "logstash-devutils", :github => "elastic/logstash-devutils", :branch => "feature/plugin-api-2_0"
can be easily automated
also I've seen a bit different .travis.yml, with the integration tests flag?
Btw, all plugins should have the integration flag set if its not already there..
I added the list of plugins done so far for passing core specs.
@suyograo logstash-codec-oldlogstashjson is marked as completed but I can't find the PR.
Here's the merge plan:
5.0.0-beta1.snapshot1 core plugins (@suyograo)plugin-api-v1) off master in all plugins repo for 2.x development (@ph)feature/plugin-api-2_0 to master in all plugins (@ph).travis.yml, Gemfile via mass update (@ph)5.0.0-beta1.snapshot1 packages for testing (@suyograo)@suyograo
2.x ?.travis.yml and Gemfile in mass update5.0.0-beta1.snapshot2 ?@colinsurprenant updated.
@suyograo @ph also, .travis.yml should not be updated to _old state_, we certainly want to keep the Java 8 selection?
@suyograo @ph core-api-v1 (not v2) branch for LS 2.x development.
@colinsurprenant We already have v1, it was before the shutdown change, and used to target LS 1.5?
@ph how is that possible? we only recently introduced the plugin-core-api gem recently
ah yes, ok, I think I remember - it's core-api, we need to create plugin-api-v1
@colinsurprenant core-api-v1 branch already exists and was created to continue development of plugins under v1 core API (pre shutdown changes, < LS 2.0). core-api-v2 once branched will match v2 of plugin APIs and continue development for them (pre Java Event, < LS 2.0).
Also, here is a .travis.yml we can mass update with: https://gist.github.com/suyograo/331f6384e143b147c09db51a854540c4
Includes Java 8 and --integration tags
Also, here is a .travis.yml we can mass update with: https://gist.github.com/suyograo/331f6384e143b147c09db51a854540c4
I am not sure we should mass update with the bundle exec rspec --tag integration, since integration usually mean that we need to add some steps in the travis file to make sure the environment is ready to be used for integration testing. Like installing redis, rabbitmq or supporting libraries.
But this could be a good way to find which plugins are failling and change their travis.yml manually.
@colinsurprenant @suyograo core-api-v2 I agree is a weird name, another option would be to make it explicit and rename them logstash-1.5.x and logstash-2.x ;)
@suyograo After discussing on slack zoom I am ok to move ahead with the core-api-v2, its only a branch name, if we change our mind in the future we can always rename it/them.
@colinsurprenant Can we move forward?
@ph @suyograo it is still confused.
For this I suggest we simply leave the core-api-v1 branch name as-is, for legacy reasons, which anyway will not be needed anymore, and introduce branches with the plugin-api name and versions.
For this I suggest we simply leave the core-api-v1 branch name as-is, for legacy reasons, which anyway will not be needed anymore, and introduce branches with the plugin-api name and versions.
@colinsurprenant @ph I am fine with naming the branch based on plugin API version. Good with plugin-api-v1
@suyograo, @ph and myself just reviewed the tasks sequence and Houston, all engines go!
Most helpful comment
@colinsurprenant @ph I am fine with naming the branch based on plugin API version. Good with
plugin-api-v1