Cron Workflows
CronWorkflows
Last updated
CronWorkflows
Last updated
Pipekit supports creating, updating, suspending, resuming and deleting Argo CronWorkflows. You can issue commands for CronWorkflows in multiple different ways:
git events
workflows
To create (submit) a CronWorkflow via git events, you must create a Pipe and link a .yaml
file to the CronWorkflow in the repo. Then when run condition is triggered, the will submit the CronWorkflow to the Cluster.
To update a CronWorkflow via git events, the procedure is the same as for CREATE
action. If you push another commit that triggers the same Pipe, the knows that the CronWorkflow is already running and in this case it will update it.
To suspend all CronWorkflows within the Pipe, use the toggle in the web interface to mark the Pipe as disabled
, this will trigger the to suspend ALL the CronWorkflows associated with the Pipe.
To resume all suspended CronWorkflows within the Pipe, use the toggle in the web interface to mark the Pipe as enabled
, this will trigger the to resume ALL the CronWorkflows associated with the Pipe.
Using Git and the YAML manifest:
Set .spec.suspend: true
in the .yaml
manifest to mark that CronWorkflow should be suspended and then trigger a new git event.
Set .spec.suspend: false
in the .yaml
manifest to mark that CronWorkflow should be resumed and then trigger a new git event.
Note: If you are using a Branch run condition, be mindful of how your YAML manifest differs across branches. Pipekit does not track or enforce YAML manifest changes across branches.
Using the Pipekit CLI:
Deleting a Pipe will also delete all Runs and logs associated with the Pipe. Everything associated with the CronWorkflow will be lost when a Pipe is deleted.
generateName
vs name
for CronWorkflowsThis can be a problem when using generateName
while submitting CronWorkflow through git events. When a new git event triggers a workflow (i.e. if a new commit is pushed), that triggers run condition, and Pipekit/ Argo Workflows will create new CronWorkflow, and will not update the existing one.
To avoid this, we recommend using name
instead of generateName
in your CronWorkflow manifests if you want to update the existing CronWorkflow Pipe instead of creating a new one.
To create a CronWorkflow with Hera Workflows:
To update:
To suspend:
To resume:
To delete:
Refer to the for how to suspend or resume specific CronWorkflows on a given cluster and namespace instead of suspending or resuming all CronWorkflows within a Pipe.
To delete a CronWorkflow, you can select Delete
under the Settings tab of the Pipe. This will trigger the to delete ALL the CronWorkflows associated with the pipe on ALL clusters.
Pipekit treats generateName
inside the CronWorkflows definition in . So, submitting multiple runs of the same CronWorkflow that are using generateName
instead of name
will result in multiple CronWorkflows
submitted to the cluster with unique names, which can cause duplicate workflows (or Pipes in the Pipekit UI) based on the same cron schedule.
For information on interacting with CronWorkflows using the Pipekit CLI, refer to the .
An example for how to define a CronWorkflow with and submit it to Pipekit with the Pipekit SDK: