Add A CLI for Workflows

[keithing]

@beckermr wrote

I wrote a similar CLI for workflows ... Are we open to a similar PR for that?

in #197. I'm moving the discussion here.

If you have written code for a workflows CLI, I think it would be a great addition. Some thoughts before we do it:

1. Are we going to run into the civis workflow and civis workflows confusion we did with notebooks? I like the solution we did in ENH CLI commands to open notebooks #197, but the CLI right now feels overloaded with both high level and low level functions in the same namespace.

2. We should make sure to write documentation. It's easier to add the documentation for new features up front rather than waiting and forgetting all the intricacies that need to be documented.

[beckermr]

civis workflows works for me and +1 for docs upfront.

I actually think getting the command space right is the hardest thing here.

The current command space is a bit cluttered and confusing:

New commands:

• submit: create a new workflow from some YAML in a file and execute it
• status: print the status of a workflow or all of your workflows depending on the invocation
• logs: print logs of each job in a workflow given an ID and an optionally an execution ID

Thin wrappers on current endpoints:

• execute: post-executions
• resume: post-executions-resume
• retry: post-executions-retry
• cancel: post-executions-cancel

The other thing is that the submit command can be built from some bash tricks.

[keithing]

That all sounds good to me!

current command space is a bit cluttered and confusing

Yeah, unfortunately. Maybe in an ideal world we'd have two different commands, one for high level and then one for the wrappers. So we'd have something like

civis files upload ...

for the wrappers and then

civisapi files post ...

to make the distinction clear. Not that I think many people are building bash scripts based on our API, that'd still be a breaking change so we need to wait on that. In the meantime, if we add wrappers like civis workflows execute we wouldn't expect that to change so I think it's a good API.