Plugins

[knownasilya]

Basically all that plugins need to do is take a config, job data, and interact with the system.

Systems could be inside of docker or some other environment.

I feel like users should be able to reuse gulp, grunt, and npm tasks easily, as well as raw bash or whatever other shell they want.

I can envision plugins exporting an array like:

// ember-cli build
module.exports = {
  name: 'ember-cli',
  droneAPIVersion: '^1.0.0',
  tasks: [{
    name: 'install',
    description: '...', // markdown?
    schema: installConfigJSONSchema,
    // function (jobData, taskConfig, cache, callback)
    action: require('./install')
  }, {
    name: 'test',
    description: '...',
    schema: testConfigJSONSchema,
    action: require('./test')
  }, {
    name: 'run',
    description: '...',
    schema: runConfigJSONSchema,
    action: require('./run')
  }, {
    name: 'cleanup',
    description: '...',
    schema: cleanupConfigJSONSchema,
    action: require('./cleanup')
  }]
]

Now the drone has the following tasks:

• ember-cli.run
• ember-cli.test
• ember-cli.install
• ember-cli.cleanup

Each of these tasks can have config options, with the defaults being sane. What each action does is up to the plugin, it could run straight up bash or use node and do fs.*, etc.

Core will send a workflow as part of the job, which is an array of tasks paired with configs for each task.

I think this is stage one of the plugins, from there we can write different base plugins that allow for easy development of different types of tasks (be extending them, etc.), like ones that run in docker or perform complicated bash stuff with ssh context, etc..

[phiros]

Sounds reasonable to me. For the workflow definition we could also maybe use a graph based approach as in http://noflojs.org/documentation/.

[knownasilya]

I agree. I was already thinking of items called modules:

• sequential
• async
• error/success
• etc

Which themselves would be tasks, but would take tasks and organize them somehow. So you could add multiple async modules in order in a sequential module. Or have an async module for the success, and a sequential for the error. So you could stack them. This would totally work with a graph based approach.

[knownasilya]

Although, I don't want to use noflojs, since it's basically a different language. I'm sure there are other projects out there that can be incorporated instead. What do you think?

[phiros]

Well noflow modules can also be written in plain javascript and graphs can also be specified in JSON (the ftb format for graphs is just more concise and IMHO easier to understand).

So far noflow seemed to me like the most promising candidate for a graph based workflow system (seems mature + active + good documentation).

[knownasilya]

If that's the case, lets do a prototype with it, and see how it works.

P.S. I can't find any documentation for the noflo npm module..