Triggers
A trigger decides when a workflow runs. With a cluster connected through the connector, you can attach one or more triggers to a workflow and dagweave fires the run for you on your cluster. You then watch the run in the executions view, with its logs and result. Triggers run workflows on your cluster, so they need the connector and a plan that includes it.
A workflow can have zero, one, or several triggers. If you have more than one connected cluster, you choose which one a trigger runs on. Every trigger reports when it last fired and its last error, so a trigger that quietly stopped working is visible.
Manual
Section titled “Manual”The simplest trigger is a button. Open the workflow in dagweave and press run. dagweave compiles the current graph, submits it through the connector, and shows you the run. This is the fastest way to test a change without wiring anything up.
A cron trigger runs the workflow on a schedule you set in the dagweave UI. It behaves like a CronWorkflow, but you manage the schedule from dagweave instead of editing a manifest. Set the cron expression, pick the cluster, and dagweave fires each run when the schedule comes due.
Deploy as a native CronWorkflow
Section titled “Deploy as a native CronWorkflow”A cron trigger keeps the schedule inside dagweave. If you would rather hand the schedule to Argo, build the workflow as a CronWorkflow and use Deploy schedule in place of Run. dagweave compiles the canvas to a CronWorkflow and applies it, along with the WorkflowTemplates it depends on, to a namespace on your connected cluster. Argo then owns the schedule and fires each run, exactly like a CronWorkflow you applied by hand. You pick the connector and namespace when you deploy.
Use a cron trigger when you want dagweave to fire and report the runs. Deploy a native CronWorkflow when you want the schedule to live in the cluster on its own.
Webhook
Section titled “Webhook”A webhook trigger gives you a URL. Post to it and the workflow runs. This is how you kick off a run from an external system such as a CI job or another service. The endpoint is secured, so only callers with the right secret can fire it, and an HMAC-signed variant is available if the caller signs its requests.
GitHub
Section titled “GitHub”A GitHub trigger runs the workflow when a matching event arrives from GitHub. You match on the repository, the event, and the branch. Supported events are a push, a pull request, and a tag. Deliveries are authenticated by GitHub’s shared webhook secret, so only real GitHub events fire the trigger.
AWS SNS
Section titled “AWS SNS”An SNS trigger runs the workflow when a message arrives on an AWS SNS topic. You point the trigger at the topic, and dagweave verifies the signature on every SNS notification, so only genuine messages from that topic fire a run.
Run provenance
Section titled “Run provenance”Every run records which trigger started it. When you look at a workflow’s history you can tell a manual run from a cron run, a webhook run, a GitHub run, or an SNS run, so you always know why a given run happened.
What is coming
Section titled “What is coming”Today’s triggers are manual, cron, webhook, GitHub, and AWS SNS. We add event sources one at a time, with the same focus on a clean setup flow, a clear view of what ran, and security first. Likely next are other AWS message queues and object-storage events, such as a file landing in a bucket.