You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I'd like to be able to add test plugins that can be tested end-to-end using our functional test runner. We have a config for this under test/plugin_functional/config.js that uses the --plugin-path CLI arg for each plugin that it loads. This PR adds support for that CLI arg to the new platform only when in development.
@azasypkin mentioned that this has not been supported because we wanted plugin discovery to be using baked-in paths. I can see how that creates some needed constraints on the discovery problem to make that implementation simpler, however I think this specific option is still useful.
This option does not add a new directory to do full discovery on. Instead it only directly to a directory for a specific plugin, not a directory to do additional discovery in (like --plugin-dir does now). @epixa are there any other known issues with allowing this option?
Update:@epixa acknowledges he's fine with option only existing in dev environment. In production we don't want relative paths to break.
joshdover
changed the title
[WIP] Add --plugin-path support for new platform plugins
[WIP] Add --plugin-path support for new platform plugins in dev
Mar 26, 2019
joshdover
changed the title
[WIP] Add --plugin-path support for new platform plugins in dev
Add --plugin-path support for new platform plugins in dev
Mar 27, 2019
Btw, once this PR merges we'll always have warning (3, one for every process) in dev mode (since x-pack is always added as an additional plugin path).
I expect this to change pretty soon between #32722 and our plan to move x-pack/plugins into a x-pack/legacy directory. We may still get this warning for the legacy directory, but that will be less confusing IMO.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
I'd like to be able to add test plugins that can be tested end-to-end using our functional test runner. We have a config for this under
test/plugin_functional/config.js
that uses the--plugin-path
CLI arg for each plugin that it loads. This PR adds support for that CLI arg to the new platform only when in development.@azasypkin mentioned that this has not been supported because we wanted plugin discovery to be using baked-in paths. I can see how that creates some needed constraints on the discovery problem to make that implementation simpler, however I think this specific option is still useful.
This option does not add a new directory to do full discovery on. Instead it only directly to a directory for a specific plugin, not a directory to do additional discovery in (like
--plugin-dir
does now). @epixa are there any other known issues with allowing this option?Update: @epixa acknowledges he's fine with option only existing in dev environment. In production we don't want relative paths to break.