Git

Your workflows stay in your own repo.

dagweave writes a standard Argo Workflows manifest to the repo and path you pick. It is Argo Workflows YAML and nothing else.

The problem

A workflow you cannot read in git.

A workflow you cannot read in git is a workflow your reviewers cannot review.

What you own

The file is yours from the first commit

The controller in your cluster runs the file. If you stopped using dagweave tomorrow, every workflow would keep running, because Argo Workflows runs it, not dagweave.

Opens and runs in anything that reads Argo Workflows.
Roll back a bad workflow with git revert.
Publishing writes a file per reusable template by default, or one file if you prefer. A dispatch sends the single-file form, under a generated name, with dagweave's ids on the pods.
Drops straight into a GitOps loop you already run.

what lands in your repoyaml

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: nightly-etl
spec:
  entrypoint: main

Publish

Commit, or open a pull request

Pick the repo, the path, and the branch. dagweave writes straight to it, or opens a PR for review.

A workflow that spans several files writes as one atomic commit.
Use a token you pass in and we never store, or the dagweave GitHub App.

publishtext

repo:   your-org/platform-workflows
path:   workflows/nightly-etl.yaml
mode:   pull request  ->  review  ->  merge

Keep your workflows where your code is.

dagweave is in early access. Leave an email and we will bring you on as we open it up.