LogoLogo
PipekitPricingBlogPipekit StatusRelease Notes
  • Introduction
  • Getting Started
  • CLI
    • Cron Workflows
  • Pipekit Agent
    • Helm Install
  • Pipekit
    • Authentication
      • Okta
    • Runs
    • Pipes
      • Managing Pipes
        • Run Conditions
        • Secrets
        • Alerting
      • Pipe Runs
        • Run Graph (DAG)
        • Pod Logs
        • Workflow Logs
        • Workflow YAML
      • Cron Workflows
      • Externally Triggered Workflows
    • Metrics
    • Templates
    • Clusters
    • Organization
      • Creating an Organization
      • Managing Users
      • Managing Alert Providers
      • Settings
      • Permissions
  • Python SDK
    • Jupyter Notebooks
    • Python Scripts
  • Self-Hosting Pipekit
    • Dependencies and Pre-requisites
    • Container Images
    • Kubernetes Permissions
    • Self-Hosted Pipekit Helm Chart
    • License Key
    • Initial Login and Break Glass Account
    • Integrating with your Git Provider
    • Configuring SSO
  • Additional Information
    • Free Trial Cluster
  • REST API
Powered by GitBook
On this page
  • git events
  • CREATE action
  • UPDATE action
  • SUSPEND and RESUME actions
  • Alternative ways to suspend and resume CronWorkflows
  • DELETE action
  • generateName vs name for CronWorkflows
  • Pipekit CLI
  • Hera
  • CREATE action
  • UPDATE action
  • SUSPEND action
  • RESUME action
  • DELETE action
  1. Pipekit
  2. Pipes

Cron Workflows

CronWorkflows

Last updated 7 months ago

Pipekit supports creating, updating, suspending, resuming and deleting Argo CronWorkflows. You can issue commands for CronWorkflows in multiple different ways:

  • git events

  • 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 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 .

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 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 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.

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:

DELETE action

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

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

Hera

from hera.workflows import Container, CronWorkflow
from pipekit_sdk.service import PipekitService
import os


pipekit = PipekitService(token=os.environ["PIPEKIT_TOKEN"])

with CronWorkflow(
    name="cron-wf-example",
    namespace="argo",
    entrypoint="main",
    schedule="*/5 * * * *",
    starting_deadline_seconds=0,
    concurrency_policy="Replace",
    service_account_name="argo-workflow"
) as w:
    main = Container(
        name="main",
        image="alpine",
        command=["sh", "-c", "echo \"I am a CronWorkflow\" && echo \"It is currently $(date)\""],
    )

pipekit.create(w, "my-cluster")

CREATE action

To create a CronWorkflow with Hera Workflows:

cw.create()

UPDATE action

To update:

cw.update()

SUSPEND action

To suspend:

cw.suspend()

RESUME action

To resume:

cw.resume()

DELETE action

To delete:

cw.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:

Pipekit CLI
Hera
Pipekit Agent
feedback@pipekit.io
Pipekit Agent
Pipekit Agent
Pipekit Agent
Pipekit CLI documentation
Pipekit Agent
the same way as kubernetes and argo do
Pipekit CLI documentation
Hera