Publishing to git
Copying YAML is always free and is one way out of dagweave. Publishing is the other: dagweave pushes the compiled workflow straight to a git repo, so your Argo Workflows GitOps setup picks it up from there and syncs it to your cluster. Publishing writes YAML to a repo, not to a cluster, so it does not need the connector.
Open the Publish action to start.
Choosing a repo
Section titled “Choosing a repo”How you pick the repo depends on whether the dagweave GitHub App is connected:
- GitHub App. When the App is installed and can reach repositories, the dialog shows a dropdown of them and publishes with a short-lived installation token minted server-side. No token to paste.
- Personal access token. When the App is not configured or reaches no repo,
the dialog falls back to a free-text
owner/namefield plus a GitHub token field. The token needsreposcope. It is passed with the one request and never stored server-side.
The publish options
Section titled “The publish options”Once a repo is chosen, you set:
- Path. Where the file lands in the repo. Defaults to
.github/workflows/workflow.yaml. - Branch. The base branch. In dropdown mode it defaults to the repo’s default
branch; in the token form it defaults to
main. - Mode. Pull request opens a PR against the branch; Direct commit commits straight to it.
- Layout. Versioned WorkflowTemplates writes the root workflow plus one file per versioned WorkflowTemplate, all in a single commit. One big megaworkflow writes everything as a single self-contained file.
Publish, and dagweave returns a link to what it created: the pull request, or the commit.
Which layout to pick
Section titled “Which layout to pick”The megaworkflow layout is one file with everything inlined, which is simple to
apply and easy to read top to bottom. The versioned layout keeps each reusable
WorkflowTemplate in its own file. The root stays at the path you chose, and the
children land in a sibling folder named after that file (publishing to
workflows/hello.yaml puts the templates in workflows/hello/). This suits a
repo where templates are shared across workflows and you want each one versioned
on its own.
After publishing
Section titled “After publishing”Publishing hands off to your own GitOps flow. Whatever watches the repo, Argo CD
or a plain kubectl apply in CI, takes the committed YAML and applies it. dagweave
does not apply it for you; that stays with the tooling that already owns your
cluster. To have dagweave run workflows directly instead, connect a cluster with
the connector and use triggers.
GitHub only, for now
Section titled “GitHub only, for now”Publishing targets GitHub, through either the App or a personal access token. The write path is abstracted, so other hosts such as GitLab can follow, but none ship yet.