thoughts

[frantjc]

will try to make a non-mess of this later

stream of consciousness:

• structs Workflow, Job, Step to marshall yaml into.
• some kind of Planner that takes said structs and turns them into some interface, say []Runnable
  • this is because someday I dream of parsing "code" files into a []Runnable rather than yaml/config files, so keeping it generic
• a step can be multiple tasks across multiple containers, as any step with uses must clone the repo being used, potentially build it, and the run the action
• some tasks (e.g. the first task of a uses step, a get step or put step) need a way to communicate info back to sequence, so Runnables need a way to tell sequence if stdout should be parsed into some kind of response that sequence can then use. this is not new for get or put (concourse already does this for its resources), but is a new (and better imo) way of approaching running actions
• need more than just the workdir mounted as a volume
  • /dev/out or something optionally mounted if the user wants the output from a Runnable somewhere on their machine
  • some kind of tool cache for "setup" actions (see setup-go, runner tool cache)
  • special volume for cloning actions into
    • should just be name the actions uses ref so it can be reused
• how to implement "special" tasks like cloning and parsing an action? I'm thinking sequence cli should have such things built right into it, and sequence mounts itself into a container and invokes itself to do them

[frantjc]

GitHub Actions (the "core" ones) are implemented using a special runs.plugin field that means something special to the runner itself. This means any action that uses runs.plugin will need to be implemented by sequence itself