workflow
The goal of the BigConfig Workflow is to enable independent development of automation units while providing a structured way to compose them into complex pipelines.
Workflow Types
Section titled “Workflow Types”tool-workflow: The fundamental unit. It renders templates and executes CLI tools (e.g., Terraform/OpenTofu, Ansible). It is driven by::params.comp-workflow: A high-level orchestrator that sequences multipletool-workflowsto create a unified lifecycle (e.g.,create,delete).
Usage Syntax
Section titled “Usage Syntax”# Execute a tool workflow directlybb <tool-workflow> <step|cmd>+ [-- <raw-command>]
# Execute a composite workflowbb <comp-workflow> <step>+Examples
Section titled “Examples”# Individual development/testingbb tool-wf-a render tofu:init -- tofu apply -auto-approvebb tool-wf-b render ansible-playbook:main.yml
# Orchestrated executionbb comp-wf-c createIn this example, comp-wf-c composes tool-wf-a and tool-wf-b.
Development and debugging happen within the individual tool workflows, while
the composite workflow manages the sequence.
Core Logic & Functions
Section titled “Core Logic & Functions”run-steps: The engine for dynamic workflow execution.prepare: Shared logic for rendering templates and initializing execution environments.parse-tool-args/parse-comp-args: Utility functions to normalize string or vector-based arguments.
Options for opts
Section titled “Options for opts”::name(required): The unique identifier for the workflow instance.::dirs(generated): Directory context for execution and output discovery. It is generated automatically byprepare.::path-fn(optional): Logic for resolving file paths.::params(optional): The input data for the workflow.
Naming Conventions
Section titled “Naming Conventions”To distinguish between the library core and the Babashka CLI implementation:
[workflow name]*: The library-level function. Requiresstep-fnsandopts.[workflow name]: The Babashka-ready task. Acceptsargsand optionalopts.
; wf.clj(defn tofu* [step-fns opts] (let [opts (prepare {::name ::tofu ::render/templates [{:template "tofu" :overwrite true :transform [["tofu" :raw]]}]} opts)] (run-steps step-fns opts)))
(defn tofu [args & [opts]] (let [opts (merge (parse-tool-args args) opts)] (tofu* [] opts))); bb.edn{:deps {group/artifact {:local/root "."}} :tasks {:requires ([group.artifact.wf :as wf]) tofu {:doc "bb tofu render tofu:init tofu:apply:-auto-approve" :task (wf/tofu *command-line-args* {:big-config/env :shell})} ansible {:doc "bb ansible render -- ansible-playbook main.yml" :task (wf/ansible *command-line-args* {:big-config/env :shell})} resource {:doc "bb resource create and delete a resource" :task (wf/resource *command-line-args* {:big-config/env :shell})}}}Decoupled Data Sharing
Section titled “Decoupled Data Sharing”Standard Terraform/HCL patterns often lead to tight coupling, where downstream resources must know the exact structure of upstream providers (e.g., the specific IP output format of AWS vs. Hetzner).
BigConfig Workflow solves this through Parameter Adaptation:
- Isolation:
tool-wf-b(Ansible) never talks directly totool-wf-a(Tofu). - Orchestration: The
comp-workflowacts as a glue layer. It uses::dirsto discover outputs from the first workflow (viatofu output --json) and maps them to the::paramsrequired by the next. - Interchangeability: You can swap a Hetzner workflow for an AWS workflow
without modifying the downstream Ansible code. Only the mapping logic in the
comp-workflowneeds to be updated.
Note: Resource naming and state booking are outside the scope of BigConfig Workflow.
(keyword->path kw)Function.
(parse-comp-args str-or-args)Function.
(parse-tool-args str-or-args)Function.
(prepare opts overrides)Function.
Prepare opts. See the namespace big-config.workflow.
(print-step-fn step opts)Function.
Print all steps of the workflow.
(run-steps)(run-steps opts)(run-steps step-fns opts)Function.
Run the steps of a tool workflow.