Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support doing a "dry run" of a bootleg task. #146

Open
holetse opened this issue Aug 2, 2017 · 2 comments
Open

Support doing a "dry run" of a bootleg task. #146

holetse opened this issue Aug 2, 2017 · 2 comments

Comments

@holetse
Copy link
Member

holetse commented Aug 2, 2017

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 with remote 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 a remote 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 conditional invokes).

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:

$ mix bootleg.build --dry-run
Dry run...
task :build started
  task :compile started
    remote :build, MIX_ENV=prod mix deps.compile
    remote :build, MIX_ENV=prod mix compile
  task :compile ended
  task :generate_release started
    remote :build, MIX_ENV=prod mix release
  task :generate_release ended
task :build ended
@holetse holetse added the feature label Aug 2, 2017
@rjanja
Copy link
Contributor

rjanja commented Aug 3, 2017

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.

@rjanja
Copy link
Contributor

rjanja commented Oct 23, 2018

It would be great to be able to use this feature to automatically generate accurate workflows documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants