Open holetse opened 7 years ago
It sounds like it may be simpler to avoid walking the AST (or doing so in a later task) and initially just going through the list of tasks registered to run. It could be left to the user to examine those tasks for calls to invoke
.
E.g.:
task :build started
before_hook :compile, fun started
before_hook :compile, fun ended
task :compile started
task :compile ended
after_hook :compile, :special_task called
after_hook :compile, :special_task ended
task :build ended
This could be simplified if we were only inspecting one-level deep:
task :build started
before_hook :compile, fun
task :compile
after_hook :compile, :special_task
task :build ended
I'm not sure how practical this is, but I love the idea of seeing the dry-run execution.
It would be great to be able to use this feature to automatically generate accurate workflows documentation.
Currently there is no way to tell exactly what tasks/hooks will get executed when a particular task is invoked, especially when another package is providing some of those tasks for you. The bootleg mix tasks would support a
--dry-run
flag, which would cause bootleg to load and parse its config files like normal, and then "run" the tasks withremote
turned into a no-op (or maybe patch into SSHKit's dry run functionality). During the run, it would print out each task/hook as they are entered/exited.The flexibility of the DSL is a bit of a disadvantage here, as things like
invoke
can be conditionalised on the results of aremote
call. Doing AST traversal, it should be possible to detect those cases and maybe the output would reflect both branches? Or warn that the results are unknown (we don't want to follow too many conditional branches if the user has a bunch of conditionalinvoke
s).This feature is probably going to need to rely on AST parsing instead of actual code execution to avoid side-effects like notifying APMs or touching files via system calls.
Example output: