Cron Workflows
CronWorkflows
Pipekit supports creating, updating, suspending, resuming and deleting Argo CronWorkflows. You can issue commands for CronWorkflows in multiple different ways:
git events
Hera workflows
git events
CREATE action
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 Pipekit Agent will submit the CronWorkflow to the Cluster.
Only one CronWorkflow YAML can run with a single Pipe on same cluster, this means every git event after the initial one will just update the existing CronWorkflow. A Pipe is linked to only one .yaml
file, so it is assumed that this is the same CronWorkflow and only updates are executed on that same CronWorkflow. This means no new CronWorkflow is triggered.
If this restriction is too heavy, please send us feedback via Slack or feedback@pipekit.io.
UPDATE action
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 Pipekit Agent knows that the CronWorkflow is already running and in this case it will update it.
SUSPEND and RESUME actions
To suspend all CronWorkflows within the Pipe, use the toggle in the web interface to mark the Pipe as disabled
, this will trigger the Pipekit Agent 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 Pipekit Agent to resume ALL the CronWorkflows associated with the Pipe.
Alternative ways to suspend and resume CronWorkflows
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:
Refer to the Pipekit CLI documentation for how to suspend or resume specific CronWorkflows on a given cluster and namespace instead of suspending or resuming all CronWorkflows within a Pipe.
DELETE action
To delete a CronWorkflow, you can select Delete
under the Settings tab of the Pipe. This will trigger the Pipekit Agent to delete ALL the CronWorkflows associated with the pipe on ALL clusters.
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 CronWorkflows
generateName
vs name
for CronWorkflowsPipekit treats generateName
inside the CronWorkflows definition in the same way as kubernetes
and argo
do. 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.
This 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.
Pipekit CLI
For information on interacting with CronWorkflows using the Pipekit CLI, refer to the Pipekit CLI documentation.
Hera
An example for how to define a CronWorkflow with Hera and submit it to Pipekit with the Pipekit SDK:
CREATE action
To create a CronWorkflow with Hera Workflows:
UPDATE action
To update:
SUSPEND action
To suspend:
RESUME action
To resume:
DELETE action
To delete:
Last updated