Chapter 6. Managing pipeline runs
Using Pipelines as Code, you can create pipelines in your code repository and run these pipelines.
6.1. Parameters and annotations in a Pipelines as Code pipeline run
To run pipelines using Pipelines as Code, you can create pipeline run definitions or templates as YAML files in the .tekton/
directory of your Git repository. You can reference YAML files in other repositories using remote URLs, but pipeline runs are triggered only by events in the repository containing the .tekton/
directory.
The Pipelines as Code resolver bundles the pipeline runs with all tasks as a single pipeline run without external dependencies.
In addition to features that exist in all pipeline runs, you can use additional parameters and annotations in pipeline run files for Pipelines as Code.
-
For pipelines, use at least one pipeline run with a spec, or a separated
Pipeline
object. - For tasks, embed the task specification inside a pipeline, or define it separately as a Task object.
6.1.1. Parameters in a pipeline run specification
You can use parameters in a pipeline run specification to provide information about the commit that triggered the pipeline run and to use the temporary GitHub App token for Github API operations.
6.1.1.1. Commit and URL information
You can specify the parameters of your commit and URL by using dynamic, expandable variables with the {{<var>}}
format. Currently, you can use the following variables:
-
{{repo_owner}}
: The repository owner. -
{{repo_name}}
: The repository name. -
{{repo_url}}
: The repository full URL. -
{{revision}}
: Full SHA revision of a commit. -
{{sender}}
: The username or account ID of the sender of the commit. -
{{source_branch}}
: The branch name where the event originated. -
{{target_branch}}
: The branch name that the event targets. For push events, it is the same as thesource_branch
. -
{{pull_request_number}}
: The pull or merge request number, defined only for apull_request
event type. -
{{git_auth_secret}}
: The secret name that is generated automatically with the Git provider token for checking out private repos.
6.1.1.2. Temporary GitHub App token for GitHub API operations
You can use the temporary installation token generated by Pipelines as Code from the GitHub App to access the GitHub API. The GitHub App generates a key for private repositories in the git-provider-token
key. You can use the {{git_auth_secret}}
dynamic variable in pipeline runs to access this key.
For example, if your pipeline run must add a comment to a pull request, you can use the a Pipelines as Code annotation to fetch the github-add-comment
task definition from Tekton Hub, and then define the task that adds the comment, as shown in the following example:
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: pipeline-with-comment
annotations:
pipelinesascode.tekton.dev/task: "github-add-comment"
spec:
pipelineSpec:
tasks:
- name: add-sample-comment
taskRef:
name: github-add-comment
params:
- name: REQUEST_URL
value: "{{ repo_url }}/pull/{{ pull_request_number }}" 1
- name: COMMENT_OR_FILE
value: "Pipelines as Code IS GREAT!"
- name: GITHUB_TOKEN_SECRET_NAME
value: "{{ git_auth_secret }}"
- name: GITHUB_TOKEN_SECRET_KEY
value: "git-provider-token"
- 1
- By using the dynamic variables, you can reuse this snippet template for any pull request from any repository that you use with Pipelines as Code.
On GitHub Apps, the generated installation token is available for 8 hours and scoped to the repository from where the events originate. You can configure the scope differently, but the expiration time is determined by GitHub.
Additional resources
6.1.2. Annotations for matching events to a pipeline run
You can match different Git provider events with each pipeline run by using annotations on the pipeline run. If there are multiple pipeline runs matching an event, Pipelines as Code runs them in parallel and posts the results to the Git provider as soon as a pipeline run finishes.
6.1.2.1. Matching a pull request event to a pipeline run
You can use the following example to match the pipeline-pr-main
pipeline run with a pull_request
event that targets the main
branch:
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: pipeline-pr-main
annotations:
pipelinesascode.tekton.dev/on-target-branch: "[main]" 1
pipelinesascode.tekton.dev/on-event: "[pull_request]"
# ...
- 1
- You can specify multiple branches by adding comma-separated entries. For example,
"[main, release-nightly]"
. In addition, you can specify the following items:-
Full references to branches such as
"refs/heads/main"
-
Globs with pattern matching such as
"refs/heads/\*"
-
Tags such as
"refs/tags/1.\*"
-
Full references to branches such as
6.1.2.2. Matching a push event to a pipeline run
You can use the following example to match the pipeline-push-on-main
pipeline run with a push
event targeting the refs/heads/main
branch:
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
name: pipeline-push-on-main
annotations:
pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]" 1
pipelinesascode.tekton.dev/on-event: "[push]"
# ...
- 1
- You can specify multiple branches by adding comma-separated entries. For example,
"[main, release-nightly]"
. In addition, you can specify the following items:-
Full references to branches such as
"refs/heads/main"
-
Globs with pattern matching such as
"refs/heads/\*"
-
Tags such as
"refs/tags/1.\*"
-
Full references to branches such as
6.1.2.3. Matching changes in paths to a pipeline run
You can match a pipeline run to changes in a set of paths. Pipelines as Code starts the pipeline run when a pull request includes changes in any of the paths that you list.
The *
wildcard denotes any file in the directory. The **
wildcard denotes any file in the directory or any subdirectories on any level under the directory.
You can use the following example to match the pipeline-pkg-or-cli
pipeline run when a pull request changes any files in the pkg
directory, the cli
directory, or any subdirectories under the cli
directory.
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-pkg-or-cli annotations: pipelinesascode.tekton.dev/on-path-changed: "["pkg/*", "cli/**"]" # ...
6.1.2.4. Excluding changes in paths from matching a pipeline run
You can configure a pipeline run to exclude matching if a pull request makes changes only to files in a specified set of paths. If the pipeline run matches an event but the pull request includes changes only to files in the paths that you list, Pipelines as Code does not start the pipeline run.
You can use the following example to match the pipeline-docs-not-generated
pipeline run when a pull request changes any files under the docs
directory or its subdirectories, except when the changes apply only to the docs/generated
directory or its subdirectories.
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-docs-not-generated annotations: pipelinesascode.tekton.dev/on-path-changed: "["docs/**"]" pipelinesascode.tekton.dev/on-path-changed-ignore: "["docs/generated/**"]" # ...
You can use the following example to match the pipeline-main-not-docs
pipeline run when a pull request targets the main
branch, except when the changes apply only to the docs
directory or its subdirectories.
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-main-not-docs annotations: pipelinesascode.tekton.dev/on-target-branch: "[main]" pipelinesascode.tekton.dev/on-event: "[pull_request]" pipelinesascode.tekton.dev/on-path-changed-ignore: "["docs/**"]" # ...
6.1.2.5. Matching a pull request label to a pipeline run
Matching pull request labels to a pipeline run is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
You can match a pipeline run to one or several pull request labels. Pipelines as Code starts the pipeline run when any of these labels is added to a pull request. When the pull request is updated with a new commit, if the pull request still has the label, Pipelines as Code starts the pipeline run again.
You can use the following example to match the pipeline-bug-or-defect
pipeline run when either the bug
label or the defect
label is added to a pull request, and also when a pull request with this label is updated with a new commit:
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-bug-or-defect annotations: pipelinesascode.tekton.dev/on-label: "[bug, defect]" # ...
The current version of Pipelines as Code supports matching events to pull request labels only for the GitHub, Gitea, and GitLab repository hosting service providers.
6.1.2.6. Matching a comment event to a pipeline run
Matching a comment event to a pipeline run is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
You can use the following example to match the pipeline-comment
pipeline run with a comment on a pull request, when the text of the comment matches the ^/merge-pr
regular expression:
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-comment annotations: pipelinesascode.tekton.dev/on-comment: "^/merge-pr" # ...
The pipeline run starts only if the comment author meets one of the following requirements:
- The author is the owner of the repository.
- The author is a collaborator on the repository.
- The author is a public member on the organization of the repository.
-
The comment author is listed in the
approvers
orreviewers
section of theOWNERS
file in the root of the repository, as defined in the Kubernetes documentation. Pipelines as Code supports the specification for theOWNERS
andOWNERS_ALIASES
files. If theOWNERS
file includes a filters section, Pipelines as Code matches approvers and reviewers only against the.*
filter.
6.1.2.7. Advanced event matching
Pipelines as Code supports using Common Expression Language (CEL) based filtering for advanced event matching. If you have the pipelinesascode.tekton.dev/on-cel-expression
annotation in your pipeline run, Pipelines as Code uses the CEL expression and skips the on-target-branch
annotation. Compared to the simple on-target-branch
annotation matching, the CEL expressions allow complex filtering and negation.
To use CEL-based filtering with Pipelines as Code, consider the following examples of annotations:
To match a
pull_request
event targeting themain
branch and coming from thewip
branch:apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-advanced-pr annotations: pipelinesascode.tekton.dev/on-cel-expression: | event == "pull_request" && target_branch == "main" && source_branch == "wip" ...
To run a pipeline only if a path has changed, you can use the
.pathChanged
suffix function with a glob pattern:apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-advanced-pr-pathchanged annotations: pipelinesascode.tekton.dev/on-cel-expression: | event == "pull_request" && "docs/\*.md".pathChanged() 1 # ...
- 1
- Matches all markdown files in the
docs
directory.
To match all pull requests starting with the title
[DOWNSTREAM]
:apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-advanced-pr-downstream annotations: pipelinesascode.tekton.dev/on-cel-expression: | event == "pull_request && event_title.startsWith("[DOWNSTREAM]") # ...
To run a pipeline on a
pull_request
event, but skip theexperimental
branch:apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: pipeline-advanced-pr-not-experimental annotations: pipelinesascode.tekton.dev/on-cel-expression: | event == "pull_request" && target_branch != experimental" # ...
For advanced CEL-based filtering while using Pipelines as Code, you can use the following fields and suffix functions:
-
event
: Apush
orpull_request
event. -
target_branch
: The target branch. -
source_branch
: The branch of origin of apull_request
event. Forpush
events, it is same as thetarget_branch
. -
event_title
: Matches the title of the event, such as the commit title for apush
event, and the title of a pull or merge request for apull_request
event. Currently, only GitHub, Gitlab, and Bitbucket Cloud are the supported providers. -
.pathChanged
: A suffix function to a string. The string can be a glob of a path to check if the path has changed. Currently, only GitHub and Gitlab are supported as providers.
In addition, you can access the full payload as passed by the Git repository provider. Use the headers
field to access the headers of the payload, for example, headers['x-github-event']
. Use the body
field to access the body of the payload, for example, body.pull_request.state
.
Using the header and body of the payload for CEL-based filtering with Pipelines as Code is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
In the following example, the pipeline run starts only if all of the following conditions are true:
-
The pull request is targeting the
main
branch. -
The author of the pull request is
superuser
. -
The action is
synchronize
; this action triggers when an update occurs on a pull request.
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: annotations: pipelinesascode.tekton.dev/on-cel-expression: | body.pull_request.base.ref == "main" && body.pull_request.user.login == "superuser" && body.action == "synchronize" # ...
If you use the header
or body
field for event matching, you might be unable to trigger the pipeline run using Git commands such as retest
. If you use a Git command, the payload body is the comment that contains this command, and not the original payload.
If you want to trigger the pipeline run again when using the body
field for event matching, you can close and reopen the pull request or merge request, or alternatively add a new SHA commit. You can add a new SHA commit by using the following command:
git commit --amend --no-edit && git push --force-with-lease
Additional resources
6.1.3. Annotations for specifying automatic cancellation-in-progress for a pipeline run
By default, Pipelines as Code does not cancel pipeline runs automatically. Every pipeline run that Pipelines as Code creates and starts executes until it completes. However, events that trigger pipeline runs can come in quick succession. For example, if a pull request triggers a pipeline run and then the user pushes new commits into the pull request source branch, each push triggers a new copy of the pipeline run. If several pushes happen, several copies can run, which can consume excessive cluster resources.
You can configure a pipeline run to enable automatic cancellation-in-progress. If you enable automatic cancellation for a pipeline run, Pipelines as Code cancels the pipeline run in the following situations:
- Pipelines as Code has successfully started a copy of the same pipeline run for the same pull request or the same source branch.
- The pull request that triggered the pipeline run is merged or closed.
You can use the following example to enable automatic cancellation when you create the sample-pipeline
pipeline run:
apiVersion: tekton.dev/v1 kind: PipelineRun metadata: name: sample-pipeline annotations: pipelinesascode.tekton.dev/cancel-in-progress: "true" # ...
Pipelines as Code cancels a pipeline run after starting a new copy of this pipeline run successfully. The pipelinesascode.tekton.dev/cancel-in-progress
setting does not ensure that only one copy of the pipeline run is executing at any time.
Automatic cancellation-in-progress of pipeline runs is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
6.2. Running a pipeline run using Pipelines as Code
With default configuration, Pipelines as Code runs any pipeline run in the .tekton/
directory of the default branch of repository, when specified events such as pull request or push occurs on the repository. For example, if a pipeline run on the default branch has the annotation pipelinesascode.tekton.dev/on-event: "[pull_request]"
, it will run whenever a pull request event occurs.
In the event of a pull request or a merge request, Pipelines as Code also runs pipelines from branches other than the default branch, if the following conditions are met by the author of the pull request:
- The author is the owner of the repository.
- The author is a collaborator on the repository.
- The author is a public member on the organization of the repository.
-
The pull request author is listed in the
approvers
orreviewers
section of theOWNERS
file in the root of the repository, as defined in the Kubernetes documentation. Pipelines as Code supports the specification for theOWNERS
andOWNERS_ALIASES
files. If theOWNERS
file includes a filters section, Pipelines as Code matches approvers and reviewers only against the.*
filter.
If the pull request author does not meet the requirements, another user who meets the requirements can comment /ok-to-test
on the pull request, and start the pipeline run.
Pipeline run execution
A pipeline run always runs in the namespace of the Repository
custom resource definition (CRD) associated with the repository that generated the event.
You can observe the execution of your pipeline runs using the tkn pac
CLI tool.
To follow the execution of the last pipeline run, use the following example:
$ tkn pac logs -n <my-pipeline-ci> -L 1
- 1
my-pipeline-ci
is the namespace for theRepository
CRD.
To follow the execution of any pipeline run interactively, use the following example:
$ tkn pac logs -n <my-pipeline-ci> 1
- 1
my-pipeline-ci
is the namespace for theRepository
CRD. If you need to view a pipeline run other than the last one, you can use thetkn pac logs
command to select aPipelineRun
attached to the repository:
If you have configured Pipelines as Code with a GitHub App, Pipelines as Code posts a URL in the Checks tab of the GitHub App. You can click the URL and follow the pipeline execution.
6.3. Restarting or canceling a pipeline run using Pipelines as Code
You can restart or cancel a pipeline run with no events, such as sending a new commit to your branch or raising a pull request. To restart all pipeline runs, use the Re-run all checks feature in the GitHub App.
To restart all or specific pipeline runs, use the following comments:
-
The
/test
and/retest
comment restarts all pipeline runs. -
The
/test <pipeline_run_name>
and/retest <pipeline_run_name>
comment starts or restarts a specific pipeline run. You can use this command to start any Pipelines as Code pipeline run on the repository, whether or not it was triggered by an event for this pipeline run.
To cancel all or specific pipeline runs, use the following comments:
-
The
/cancel
comment cancels all pipeline runs. -
The
/cancel <pipeline_run_name>
comment cancels a specific pipeline run.
The results of the comments are visible under the Checks tab of the GitHub App.
The comment starts, restarts, or cancels any pipeline runs only if the comment author meets one of the following requirements:
- The author is the owner of the repository.
- The author is a collaborator on the repository.
- The author is a public member on the organization of the repository.
-
The comment author is listed in the
approvers
orreviewers
section of theOWNERS
file in the root of the repository, as defined in the Kubernetes documentation. Pipelines as Code supports the specification for theOWNERS
andOWNERS_ALIASES
files. If theOWNERS
file includes a filters section, Pipelines as Code matches approvers and reviewers only against the.*
filter.
Using a comment to start a pipeline run that does not match an event is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
Procedure
- If you target a pull request and you use the GitHub App, go to the Checks tab and click Re-run all checks.
If you target a pull or merge request, use the comments inside your pull request:
Example comment that cancels all pipeline runs
This is a comment inside a pull request. /cancel
If you target a push request, include the comments within your commit messages.
NoteThis feature is supported for the GitHub provider only.
- Go to your GitHub repository.
- Click the Commits section.
- Click the commit where you want to restart a pipeline run.
Click on the line number where you want to add a comment.
Example comment that starts or restarts a specific pipeline run
This is a comment inside a commit. /retest example_pipeline_run
NoteIf you run a command on a commit that exists in multiple branches within a push request, the branch with the latest commit is used.
This results in two situations:
-
If you run a command on a commit without any argument, such as
/test
, the test is automatically performed on themain
branch. -
If you include a branch specification, such as
/test branch:user-branch
, the test is performed on the commit where the comment is located with the context of theuser-branch
branch.
-
If you run a command on a commit without any argument, such as
6.4. Monitoring pipeline run status using Pipelines as Code
Depending on the context and supported tools, you can monitor the status of a pipeline run in different ways.
Status on GitHub Apps
When a pipeline run finishes, the status is added in the Check tabs with limited information on how long each task of your pipeline took, and the output of the tkn pipelinerun describe
command.
Log error snippet
When Pipelines as Code detects an error in one of the tasks of a pipeline, a small snippet consisting of the last 3 lines in the task breakdown of the first failed task is displayed.
Pipelines as Code avoids leaking secrets by looking into the pipeline run and replacing secret values with hidden characters. However, Pipelines as Code cannot hide secrets coming from workspaces and envFrom source.
Annotations for log error snippets
In the TektonConfig
custom resource, in the pipelinesAsCode.settings
spec, you can set the error-detection-from-container-logs
parameter to true
. In this case, Pipelines as Code detects the errors from the container logs and adds them as annotations on the pull request where the error occurred.
Adding annotations for log error snippets is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
Currently, Pipelines as Code supports only the simple cases where the error looks like makefile
or grep
output of the following format:
<filename>:<line>:<column>: <error message>
You can customize the regular expression used to detect the errors with the error-detection-simple-regexp
parameter. The regular expression uses named groups to give flexibility on how to specify the matching. The groups needed to match are filename
, line
, and error
. You can view the Pipelines as Code config map for the default regular expression.
By default, Pipelines as Code scans only the last 50 lines of the container logs. You can increase this value in the error-detection-max-number-of-lines
field or set -1
for an unlimited number of lines. However, such configurations may increase the memory usage of the watcher.
Status for webhook
For webhook, when the event is a pull request, the status is added as a comment on the pull or merge request.
Failures
If a namespace is matched to a Repository
custom resource definition (CRD), Pipelines as Code emits its failure log messages in the Kubernetes events inside the namespace.
Status associated with Repository CRD
The last 5 status messages for a pipeline run is stored inside the Repository
custom resource.
$ oc get repo -n <pipelines-as-code-ci>
NAME URL NAMESPACE SUCCEEDED REASON STARTTIME COMPLETIONTIME pipelines-as-code-ci https://github.com/openshift-pipelines/pipelines-as-code pipelines-as-code-ci True Succeeded 59m 56m
Using the tkn pac describe
command, you can extract the status of the runs associated with your repository and its metadata.
Notifications
Pipelines as Code does not manage notifications. If you need to have notifications, use the finally
feature of pipelines.
Additional resources
Additional resources
6.5. Cleaning up pipeline run using Pipelines as Code
There can be many pipeline runs in a user namespace. By setting the max-keep-runs
annotation, you can configure Pipelines as Code to retain a limited number of pipeline runs that matches an event. For example:
...
pipelinesascode.tekton.dev/max-keep-runs: "<max_number>" 1
...
- 1
- Pipelines as Code starts cleaning up right after it finishes a successful execution, retaining only the maximum number of pipeline runs configured using the annotation.Note
- Pipelines as Code skips cleaning the running pipelines but cleans up the pipeline runs with an unknown status.
- Pipelines as Code skips cleaning a failed pull request.
6.6. Using incoming webhook with Pipelines as Code
Using an incoming webhook URL and a shared secret, you can start a pipeline run in a repository.
To use incoming webhooks, specify the following within the spec
section of the Repository
custom resource definition (CRD):
- The incoming webhook URL that Pipelines as Code matches.
The Git provider and the user token. Currently, Pipelines as Code supports
github
,gitlab
, andbitbucket-cloud
.NoteWhen using incoming webhook URLs in the context of GitHub app, you must specify the token.
- The target branches and a secret for the incoming webhook URL.
Example: Repository
CRD with incoming webhook
apiVersion: "pipelinesascode.tekton.dev/v1alpha1" kind: Repository metadata: name: repo namespace: ns spec: url: "https://github.com/owner/repo" git_provider: type: github secret: name: "owner-token" incoming: - targets: - main secret: name: repo-incoming-secret type: webhook-url
Example: The repo-incoming-secret
secret for incoming webhook
apiVersion: v1 kind: Secret metadata: name: repo-incoming-secret namespace: ns type: Opaque stringData: secret: <very-secure-shared-secret>
To trigger a pipeline run located in the .tekton
directory of a Git repository, use the following command:
$ curl -X POST 'https://control.pac.url/incoming?secret=very-secure-shared-secret&repository=repo&branch=main&pipelinerun=target_pipelinerun'
Pipelines as Code matches the incoming URL and treats it as a push
event. However, Pipelines as Code does not report status of the pipeline runs triggered by this command.
To get a report or a notification, add it directly with a finally
task to your pipeline. Alternatively, you can inspect the Repository
CRD with the tkn pac
CLI tool.