radiant cedar
Consider a deployment or release workflow which is not fully automated, and perhaps cannot be since it involves something like legal compliance, internationalization QA, sending an email and waiting for a reply, or some other step where Dagger needs to stop executing for a while, some human somewhere needs to be put on task with inputs generated by the CI steps before it, that human generates outputs which are then fed back into the next CI step along with some unchanged outputs from the earlier steps, and then Dagger picks back up from here.
I’m curious about how to model this with any automation tool. I don’t have any existing examples, but I can think of a few things that would or would not work in theory.
For example, a naive (and unrealistic) solution would be to simply block a dagger function on user input. If the human task doesn’t take long and the human can be activated immediately to do the task, this is almost workable. But typically neither of these constraints will apply and then your CI is churning through n minutes of compute time waiting for the human to do their thing. On the bright side, your CI status (assuming timeout is impossible) will show the success or failure status of the entire flow, including the human process.
Conceptually, what might need to happen instead is the dagger process calls an external work management queue to activate the human step, uploads assets needed by that step (or perhaps even spins up servers on persistent infrastructure), serializes some of its own state to storage, then exits with success. Then when the human step is completed, a new Dagger process is started which receives input from the human step, recovers its state from storage, and continues. This does not sound super fun to model, although I could be overstating this. The ability to track the status of the full process from your SCM host requires it be able to enter a paused/pending state and then receive status updates far into the future.
woeful forum
winter swift
dire oxide