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
A new plugin system in which cargo-make exposes task meta data and sub task execution capabilities (for example, only execute env setup or conditions).
Users can than setup an alternate executor implemented in duckscript using the meta data/sub execution capabilities.
This would enable to create custom solutions, beyond what cargo-make provides (for example, running a task in a container like requested in #619).
Describe The Solution You'd Like
A task would be able to define an optional plugin for alternate executer.
In which case, cargo-make calls the plugin script with task data and does not execute it on its own
[tasks.mytask]
plugin = "example-executer"command = "cargo"args = ["test"]
[plugins.impl.example-executer]
script = '''# implement logic of task execution here, using task meta data.echo Running task: ${task.name}if cm_task_condition ${task.name} echo condition passed exec --fail-on-error ${task.command} # naturally this is ignoring lots of stuff and just a very simple exampleelse echo condition failed, skippingend'''
You could 'switch' implementation using aliases
[plugins.impl.old]
# code here...
[plugins.impl.new]
# code here...
[plugins.aliases]
old = "new"# calling old plugin which get redirected to new
Few capabilities exposed to duckscript plugins come to mind:
execute task env setup
execute task condition to get true/false
execute cargo-make functions on command args
execute dependencies
All task meta data would be available via 'task' namespace as duckscript variables to be used by the plugin script, for example
task.name
task.description
task.command
task.args <- list handle
task.script <- list handle
task.env.env_set <- list handle
task.env.env_unset <- list handle
and so on...
Few env vars would be set before calling the plugin (apart of the current task env vars that are already set today such as task name and so on...)
CARGO_MAKE_TASK_PLUGIN_NAME - the value defined in the task
CARGO_MAKE_TASK_PLUGIN_IMPL - the actual plugin name (after aliases)
The text was updated successfully, but these errors were encountered:
Feature Description
A new plugin system in which cargo-make exposes task meta data and sub task execution capabilities (for example, only execute env setup or conditions).
Users can than setup an alternate executor implemented in duckscript using the meta data/sub execution capabilities.
This would enable to create custom solutions, beyond what cargo-make provides (for example, running a task in a container like requested in #619).
Describe The Solution You'd Like
A task would be able to define an optional plugin for alternate executer.
In which case, cargo-make calls the plugin script with task data and does not execute it on its own
You could 'switch' implementation using aliases
Few capabilities exposed to duckscript plugins come to mind:
All task meta data would be available via 'task' namespace as duckscript variables to be used by the plugin script, for example
task.name
task.description
task.command
task.args <- list handle
task.script <- list handle
task.env.env_set <- list handle
task.env.env_unset <- list handle
and so on...
Few env vars would be set before calling the plugin (apart of the current task env vars that are already set today such as task name and so on...)
CARGO_MAKE_TASK_PLUGIN_NAME - the value defined in the task
CARGO_MAKE_TASK_PLUGIN_IMPL - the actual plugin name (after aliases)
The text was updated successfully, but these errors were encountered: