Closed lanthias closed 7 years ago
I think on 2&3, do DSL in a workflow file first and then reveal the start
command on the CLI takes any DSL expression which evaluates to a workflow?
Is
// workflow.nml
def fooSource = source(http:///foo : Text)
def myWorkflow = fooSource | someModule.numChars | sink(stdout:// : Integer)
going to work in AA, or will it fail because fooSource
is not defined by the time myWorkflow
is evaluated (cc/ @NickPollard)?
If it fails, I think I'll just go with CLI and not mention that it 'can' be done in the DSL
Yes good question.
There is the question of how we want to structure this. For instance, I find myself creating a sources
and a sinks
module where I define my sources and sinks, and then building a separate workflow from them.
I agree you should show you can either put DSL in a file or do it manually. There could be an argument that doing it manually first is less of a barrier to entry for the first-time user though?
There could be an argument that doing it manually first is less of a barrier to entry for the first-time user though?
I think it depends on if (1) involves editing / creating some IDL/DSL. Were you envisaging just calls to the build command or lifecycle from init?
I think looking at workflow DSL files might be better off after nstackcom/nstack#114. I'm at least going to hold off on it for my first pass at this
We have a v1 of this, so closing and reopening another issue for more advanced quick start
User Story
Notes
I want thinking of something like, but some steps might be redundant?
Questions