Run Conditions

This feature is only available to Pipes that have been created via the Pipekit Web UI.

You can choose which git event(s) trigger the execution of a Pipe, and on which cluster the resulting pipe is executed. You can choose from the following options:

• Git Branch

• Git Tag

• Git Pull/Merge Request

For each one, you can choose a specific name (eg Branch="main") or a regex (eg Branch="^feature/.*$"). Finally, for each source type and name/regex, you can define which cluster the workflow is executed on.

For example, any git branches that match the regex ^feature/.*$ could trigger the Pipe to run on the dev cluster, any git branches that match the regex ^release/.*$ could trigger the Pipe to run on the staging cluster, and any git branches that match the regex ^main$ could trigger the Pipe to run on the prod cluster.

You can choose multiple options. If you do so, the Pipe will run if any of the options are met.

Pull/Merge Request Labels

If there are labels for your pull/merge requests to be used (github, gitlab), you can choose which labels will trigger the Pipe Run. To use this feature, while creating a pipe, choose the Pull Request Run Condition Source Type, and then select the label(s) you want to match against.

When a pull/merge request is submitted to the repository, Pipekit will check if the pull/merge request labels match the run condition labels you have selected. The pipe will then trigger a run if one of the the run condition labels match the pull/merge request labels.

If you leave the labels field blank, the Pipe will run for all pull/merge requests matching the regex.

Currently, Pipekit only supports selecting run condition labels when creating a pipe from scratch. You can't modify an existing Pipe's run condition labels after the pipe has been created.

Environment variables and Pipe information

When triggering a Pipe via git, Pipekit injects some environment variables into the running workflow. These variables can be used to get information about the git event that triggered the Pipe and can be used by the Workflow to make decisions based on that information.

Environment Variable	Description
GIT_BRANCH_NAME	The name of the branch that the pull/merge request belongs to. Blank if triggered by a git tag event.
GIT_COMMIT	Either the sha1 of the pull/merge request. Or the name of the branch or tag that triggered the workflow.
GIT_ORG	The name of the organization that owns the repository that triggered the workflow. For github.com/pipekit/examples, it would be pipekit.
GIT_REPO_NAME	The name of the repository that triggered the workflow. For github.com/pipekit/examples, it would be examples.
GIT_REQUEST_NUMBER	The PR/MR number that triggered the Pipe run. Blank if not triggered by a pull/merge request.
GIT_SHA	The sha1 for the commit. Blank if triggered by a git tag event.
GIT_TAG	The git tag name that triggered the Pipe run. Blank if the Pipe run was not triggered by a git tag event.
GIT_TARGET_BRANCH	The name of the target branch of the pull/merge request. Blank if not triggered by a PR/MR.

Pipe information

Pipekit also injects labels into your running workflow, which you could turn into environment variables:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: get-pipe-info
spec:
  templates:
    - name: get-pipe-info
      container:
        env:
        - name: RUN_UUID
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['workflows.pipekit.io/run_uuid']
        - name: PIPE_UUID
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['workflows.pipekit.io/pipe_uuid']
        image: alpine
        command:
          - sh
          - -c
          - |
            echo: "$RUN_UUID"
            echo: "$PIPE_UUID"
            echo: "https://pipekit.io/pipes/$PIPE_UUID/runs/$RUN_UUID"