#interactive modules
1 messages · Page 1 of 1 (latest)
Pretty skeptic of exposing them in Dagger at least. Having your pipeline halt because of a single interactive module deep in your stack would be pretty awful. Not sure if that would happen though, it's not like that's prevented by regular old programming languages. It's the dev's responsibility to only put stuff like this at the "tippity top"
It's common in Jenkins pipelines to wrap sub-pipelines for handling templating and compliance rules. For example, a platform engineering team puts a step in the parent pipeline that requires manual approval before the remainder runs. These cases are in more regulated environments, from my experience.
In short, I see a use case for compliance and organizational policy purposes.
In a world where you could hypothetically take the output from a dev build and promote it to an environment, you might want to have an optional approval step.
I bet there are other less compliancy use cases too.
Ah right - that brings back memories: https://github.com/concourse/rfcs/pull/36#pullrequestreview-336557490
That case is pretty interesting, because the approval might come in days later (CI pipeline ran on Friday). I mean, a CLI prompt would support that obviously, but it's kinda goofy
sorry missed the thread…
Yes but of the async variety
Lots of workflows require eg. a manual approval step, which may take days to secure. Not having a primitive for that leaves some Dagger pipelines doomed to being forever sliced up within some other system that does
np, I should use the 🧵 emoji to warn 😛
BUT maybe it’s not about the “prompt” primitive, but the ability to run a pipeline async somehow (the “prompting being just an example of what you could build on top of that”)
Yeah - it'd be nice if they were both one primitive, and the CLI was just one UI for it
As for interactive prompting I think we could get a lot of mileage out of the CLI prompting interactively for missing mandatory arguments
would solve the “don’t put it deep in the call tree” problem
oh wait - by arguments do you mean to a Zenith function? or to the CLI itself? (guessing both either way)
then yeah, that'd be nice, since it's ultimately reduced down to arguments
maybe we could have a convention where the arg doc string also works nicely as a prompt
to a function (via the CLI). so both?
would be nice for dagger mod init for example, since it has two required flags
This is where (amazingly) the CUE syntax had a built-in advantage, because you could easily express constraints on allowed values. We had various prototypes over the years of exactly what we're talking about (auto-prompting in the CLI) with eg. dropdowns for enum values etc. A bit harder to pull off in the current DX though
neat - it seems doable from the GraphQL schema at least, but yeah more legwork for us