Conditions

This document defines Conditions and their capabilities.

Syntax

To define a configuration file for a Condition resource, you can specify thefollowing fields:

  • Required:
    • apiVersion - Specifies the API version, for exampletekton.dev/v1alpha1.
    • kind - Specify the Condition resource object.
    • metadata - Specifies data to uniquely identify theCondition resource object, for example a name.
    • spec - Specifies the configuration information foryour Condition resource object. In order for a Condition to do anything,the spec must include:
    • check - Specifies a container that you want to run for evaluating the condition
    • description - Description of the Condition.

Check

The check field is required. You define a single check to define the body of a Condition. Thecheck must specify a Step. The container image runs till completion. The containermust exit successfully i.e. with an exit code 0 for the condition evaluation to be successful. All otherexit codes are considered to be a condition check failure.

Description

The description field is an optional field and can be used to provide description of the Condition.

Parameters

A Condition can declare parameters that must be supplied to it during a PipelineRun. Sub-fieldswithin the check field can access the parameter values using the templating syntax:

  1. spec:
  2. parameters:
  3. - name: image
  4. default: ubuntu
  5. check:
  6. image: $(params.image)

Parameters name are limited to alpha-numeric characters, - and and canonly start with alpha characters and . For example, fooIs-Bar_ is a validparameter name, barIsBa$ or 0banana are not.

Each declared parameter has a type field, assumed to be string if not provided by the user.The other possible type is array — useful, for instance, checking that a pushed branch name doesn’t match any ofmultiple protected branch names. When the actual parameter value is supplied, its parsed typeis validated against the type field.

Resources

Conditions can declare input PipelineResources via the resources field toprovide the Condition container step with data or context that is needed to perform the check.

Resources in Conditions work similar to the way they work in Tasks i.e. they can be accessed usingvariable substitution and the targetPath field can be usedto control where the resource is mounted

Labels

Labels defined as part of the Condition metadata will be automatically propagated to the Pod.

Examples

For complete examples, seethe examples folder.