artilleryio / artillery

The complete load testing platform. Everything you need for production-grade load tests. Serverless & distributed. Load test with Playwright. Load test HTTP APIs, GraphQL, WebSocket, and more. Use any Node.js module.
https://www.artillery.io
Mozilla Public License 2.0
7.92k stars 505 forks source link

Question: Locally sourced plugins #331

Open ericmacfa opened 7 years ago

ericmacfa commented 7 years ago

I did see the plugin docs.

I looks like plugins can easily be added to a config, as long as they're installed as a module dependency (so they can be require()d by module name).

Is it possible to tell the plugin loader to load the plugin from a local directory instead?

ericmacfa commented 7 years ago

Trial and error yielded an answer: Assuming your project structure looks something like this

project_root ($ for brevity)
|   package.json
+---MyPlugin/
|       index.js
+---tests/
|       example-test.yml
+---util/
|       request-utils.js

You can get Artillery to load a plugin from $/MyPlugin/ with the below yml config:

config:
  plugins:
    MyPlugin:
      scope: '../../../' # This path gets loaded relative to $/node_modules/artillery-core/lib/runner.js

The key detail being the scope property in the plugin's config.

Without the scope set, Artillery will simply require a module with the name artillery-plugin-MyPlugin

Setting the scope lets us change the prefix that Artillery uses to require the plugin, and we can point it at a local dir.

hassy commented 7 years ago

Re-opening as this needs to be documented (and plugins in general).

Thanks @ericmacfa

antony commented 4 years ago

It would be great to allow a plugin to self-test by including a yaml file in the plugin source, and load the plugin from the same directory.

However even with scope, this seems impossible, as it's doing a simple string concatenation.

How do people feel about there being a path attribute for plugins, which would allow:

  config:
    plugins:
      myPlugin: {
        path: './index.js'
      }

This would solve local plugin paths as well, so it might be possible to do away with the (imho less flexible) scope attribute.

Thoughts?