Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 5. Creating pipeline runs in Pipelines as Code

To create pipeline run definitions, first integrate Pipelines as Code with your repository provider and define your repository by using the Repository custom resource (CR).

5.1. Creating a pipeline run in Pipelines as Code
Link kopieren

You can create a pipeline run definition for Pipelines as Code in your repository and match it to an event, such as a pull request. When the event happens, Pipelines as Code creates a PipelineRun custom resource (CR) from this definition, and then OpenShift Pipelines executes the pipeline run.

Prerequisites

  • You configured Pipelines as Code to integrate with your Git repository hosting service provider.
  • You created a Repository CR to define the connection to your repository in Pipelines as Code.
  • You have a .tekton directory in the root of your repository.

Procedure

  1. Create a file with a .yaml or .yml extension in the .tekton directory.
  2. In the file that you created, create a YAML specification for a PipelineRun CR. This specification can use all features of OpenShift Pipelines.

  3. Depending on the requirements of your pipeline run definition, complete any of the following optional steps:

    • Create other files with a .yaml or .yml extension in the .tekton directory. In these files, give definitions of resources that your pipeline run definition references, such as Pipeline, Task, or StepAction CRs. The Pipelines as Code resolver automatically resolves these resources and includes them in the PipelineRun CR that uses your definition.

    • Use dynamic variables in your pipeline run specification. Pipelines as Code replaces these variables with values that represent the current context. For example, {{ repo_url }} is the current URL for the repository and {{ revision }} is the commit SHA that started the pipeline run.

      For more information about dynamic variables, see the "Dynamic variables in a pipeline run specification" section.

    • Add one or more Pipelines as Code resolver annotations to your pipeline run definition. A Pipelines as Code resolver annotation references a pipeline or task in Tekton Hub, an HTTP location, or a location in your repository outside the .tekton directory. If you create a Pipelines as Code resolver annotation to reference a resource, you can use this resource by name in your pipeline run definition. The Pipelines as Code resolver automatically resolves these resources and includes them in the PipelineRun CR that uses your definition.

      For more information about these annotations, see the "Pipelines as Code resolver annotations" section.

  4. Match the pipeline run to events by adding any of the following annotations to the pipeline run definition. When the defined event happens, Pipelines as Code starts the pipeline run. For more information about matching the pipeline run to events, see the "Annotations for matching events to a pipeline run" section.

    • A combination of the pipelinesascode.tekton.dev/on-event annotation, which defines a pull request or push event, and a pipelinesascode.tekton.dev/on-target-branch annotation, which defines the branch that the pull request or push event must target. If you match your pipeline run to a pull request or push event, the pipeline run starts when a user creates the event. For pull requests, it starts again each time the user updates the source branch event.

      Note

      If your Git repository provider uses merge requests and not pull requests, a pull_request event definition matches a merge request.

    • A pipelinesascode.tekton.dev/on-comment annotation, which matches the pipeline run to a comment on a pull request by regular expression. If you match your pipeline run to a comment, it starts when someone adds the comment to a pull request. To start the pipeline run again, add the comment again.
    • A pipelinesascode.tekton.dev/on-cel-expression annotation, which matches the pipeline run if the specified Common Expression Language (CEL) expression evaluates to true on a pull request or push event.

  5. Optional: Add one or more annotations that filter the matching events. With these annotations, when the defined matching event (such as a pull request, a push event, or a comment) happens, Pipelines as Code checks if these annotations are also matched. The pipeline run starts only if all the annotations that you added to it match the event. For more information about filtering matching events, see the "Annotations for filtering events" section.

    • The event matches a pipelinesascode.tekton.dev/on-path-changed annotation if the pull request or push event affect files in the specified paths.
    • A pipelinesascode.tekton.dev/on-path-changed-ignore annotation excludes matching the event if the event changes only files in the specified paths and does not change any other files in the repository.
    • The event matches a pipelinesascode.tekton.dev/on-label annotation if the pull request or push event has one of the specified labels.
  6. Optional: Add the pipelinesascode.tekton.dev/cancel-in-progress: "true" annotation to enable automatic cancellation of the pipeline run in certain cases. 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 you enable automatic cancellation-in-progress, after a new copy of the pipeline run starts, Pipelines as Code cancels the older run to avoid running many copies of the pipeline run at the same time. For more information about this annotation, see the "Annotations for specifying automatic cancellation-in-progress for a pipeline run" section.

Example Pipelines as Code pipeline run definition

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: maven-build
annotations:
  pipelinesascode.tekton.dev/task: "[git-clone]"
  pipelinesascode.tekton.dev/on-event: "[pull_request]"
  pipelinesascode.tekton.dev/on-target-branch: "[main, release]"
  pipelinesascode.tekton.dev/on-path-changed: "[src/**]"
  pipelinesascode.tekton.dev/cancel-in-progress: "true"
spec:
  pipelineSpec:
    workspaces:
    - name: shared-workspace
    tasks:
      - name: fetch-repo
        taskRef:
          - name: git-clone
        params:
        - name: url
          value: {{ repo_url }}
        - name: revision
          value: {{ revision }}
        workspaces:
        - name: output
          workspace: shared-workspace
      - name: build-from-source
        taskRef:
          resolver: cluster
          params:
          - name: kind
            value: task
          - name: name
            value: maven
          - name: namespace
            value: openshift-pipelines
        workspaces:
        - name: source
          workspace: shared-workspace

pipelinesascode.tekton.dev/task
References the git-clone task from Tekton Hub.
pipelinesascode.tekton.dev/on-event
Matches the pipeline run to a pull request or merge request event.
pipelinesascode.tekton.dev/on-target-branch
Specifies that a pull request into either the main branch or release branch triggers this pipeline run.
pipelinesascode.tekton.dev/on-path-changed
Specifies that the pipeline run triggers only if the pull request has changes to files under the src directory.
pipelinesascode.tekton.dev/cancel-in-progress
Specifies that, if Pipelines as Code starts the pipeline run again for the same pull request, Pipelines as Code cancels the earlier run.
tasks.name
The pipeline run specification references the git-clone task by name. Because of the pipelinesascode.tekton.dev/task annotation, the Pipelines as Code resolver resolves this reference to the git-clone task from Tekton Hub.
params.repo_url
Pipelines as Code replaces the {{ repo_url }} dynamic variable with the URL for the Git repository.
params.revision
Pipelines as Code replaces the {{ revision }} dynamic variable with the revision of the branch for which Pipelines as Code started the pipeline run.

5.2. Dynamic variables in a pipeline run specification
Link kopieren

You can use dynamic variables in a pipeline run specification to give information about the triggering commit. You can also use these variables with the temporary GitHub App token for GitHub API operations.

You can use dynamic variables in a pipeline run specification to give information about the triggering commit. You can also use these variables with the temporary GitHub App token for GitHub API operations.

Important

Using Pipelines as Code dynamic variables in default values for pipeline or task parameters is currently not supported. You can use a dynamic variable in a value: field, but not in a default: field.

5.2.1. Commit and URL information
Link kopieren

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 the source_branch.
  • {{pull_request_number}}: The pull or merge request number, defined only for a pull_request event type.
  • {{git_auth_secret}}: The secret name that Pipelines as Code generates automatically with the Git provider token for checking out private repositories.

5.2.2. Temporary GitHub App token for GitHub API operations
Link kopieren

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 a Pipelines as Code annotation to fetch the github-add-comment task definition from Tekton Hub. You can 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 }}"
          - 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"
REQUEST_URL
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.
Note

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 GitHub determines the expiration time.

5.3. Pipelines as Code resolver annotations
Link kopieren

You can use Pipelines as Code resolver annotations to reference Task and Pipeline custom resource (CR) definitions. The Pipelines as Code resolver fetches the definitions from the locations that you specify in the annotations. If there is any error while fetching the remote tasks or parsing them, Pipelines as Code stops processing the tasks.

If you reference a remote task in a pipeline run, or a pipeline in a PipelineRun or a PipelineSpec object, the Pipelines as Code resolver automatically resolves the referenced resource and includes it in the resulting PipelineRun CR.

Note

Red Hat deprecated the public instance of Tekton Hub (hub.tekton.dev) and will remove it in a future release. Use Artifact Hub as an alternative for Tekton Pipeline and Task resources:

Artifact Hub is open source and supports self-hosting, providing greater flexibility for managing your Tekton Pipeline and Task resources.

5.3.1. Remote task annotations
Link kopieren

To include remote tasks, see the following examples of annotation:

You can include remote tasks in your pipeline runs by using specific annotations. Refer to the following examples to configure your tasks.

Reference remote tasks in Tekton Hub

  • Reference a single remote task in Tekton Hub. 

    ...
  pipelinesascode.tekton.dev/task: "git-clone"
...
    pipelinesascode.tekton.dev/task
    Pipelines as Code includes the latest version of the task from the Tekton Hub.

  • Reference many remote tasks from Tekton Hub 

    ...
  pipelinesascode.tekton.dev/task: "[git-clone, golang-test, tkn]"
...

  • Reference many remote tasks from Tekton Hub using the -<NUMBER> suffix. 

    ...
  pipelinesascode.tekton.dev/task: "git-clone"
  pipelinesascode.tekton.dev/task-1: "golang-test"
  pipelinesascode.tekton.dev/task-2: "tkn"
...
    pipelinesascode.tekton.dev/task-2
    By default, Pipelines as Code interprets the string as the latest task to fetch from Tekton Hub.

  • Reference a specific version of a remote task from Tekton Hub. 

    ...
  pipelinesascode.tekton.dev/task: "[git-clone:0.1]"
...
    pipelinesascode.tekton.dev/task
    Refers to the 0.1 version of the git-clone remote task from Tekton Hub.

Remote tasks by using URLs

...
  pipelinesascode.tekton.dev/task: "<https://remote.url/task.yaml>"
...

pipelinesascode.tekton.dev/task

The public URL to the remote task.

Note

  • If you use GitHub and the remote task URL uses the same host as the Repository custom resource definition (CRD), Pipelines as Code uses the GitHub token and fetches the URL using the GitHub API.

    For example, if your repository URL is similar to https://github.com/<organization>/<repository> and the remote HTTP URL references a GitHub blob, Pipelines as Code fetches the task definition files from that private repository by using the GitHub App token.

    When you work on a public GitHub repository, Pipelines as Code acts similarly for a GitHub raw URL such as https://raw.githubusercontent.com/<organization>/<repository>/<mainbranch>/<path>/<file>.

  • Pipelines as Code scopes GitHub App tokens to the owner or organization where the repository resides. When you use the GitHub webhook method, you can fetch any private or public repository on any organization that allows the personal token.

Reference a task from a YAML file inside your repository

...
pipelinesascode.tekton.dev/task: "<share/tasks/git-clone.yaml>"
...

pipelinesascode.tekton.dev/task
Relative path to the local file containing the task definition.

5.3.2. Remote pipeline annotations
Link kopieren

You can share a pipeline definition across many repositories by using the remote pipeline annotation. 

...
    pipelinesascode.tekton.dev/pipeline: "<https://git.provider/raw/pipeline.yaml>"
...
pipelinesascode.tekton.dev/pipeline
URL to the remote pipeline definition. You can also give locations for files inside the same repository.
Note

You can reference only one pipeline definition using the annotation.

5.3.2.1. Overriding a task in a remote pipeline
Link kopieren

By default, if you use a remote pipeline annotation in a pipeline run, Pipelines as Code uses all the tasks that are a part of the remote pipeline.

You can override a task in a remote pipeline by adding a task annotation to the pipeline run. The added task must have the same name as a task in the remote pipeline.

For example, you might use the following pipeline run definition:

Example pipeline run definition referencing a remote pipeline and overriding a task

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  annotations:
    pipelinesascode.tekton.dev/pipeline: "https://git.provider/raw/pipeline.yaml"
    pipelinesascode.tekton.dev/task: "./my-git-clone-task.yaml"

For this example, assume the remote task found at https://git.provider/raw/pipeline.yaml includes a task named git-clone and the task that the my-git-clone-task.yaml file defines is also named git-clone.

In this case, the pipeline run executes the remote pipeline, but replaces the task named git-clone in the pipeline with the task you defined.

5.4. Annotations for matching events to a pipeline run
Link kopieren

You can match different Git provider events with each pipeline run by using annotations on the pipeline run. If there are many 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.

You can match different Git provider events with each pipeline run by using annotations on the pipeline run. If there are many 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.

5.4.1. Matching a pull request event to a pipeline run
Link kopieren

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]"
  pipelinesascode.tekton.dev/on-event: "[pull_request]"
# ...
pipelinesascode.tekton.dev/on-target-branch

You can specify many 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.\*"

5.4.2. Matching a push event to a pipeline run
Link kopieren

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]"
  pipelinesascode.tekton.dev/on-event: "[push]"
# ...
pipelinesascode.tekton.dev/on-target-branch

You can specify many 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.\*"

5.4.3. Matching a comment event to a pipeline run
Link kopieren

Important

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 OWNERS file lists the comment author in the approvers or reviewers section in the root of the repository, as defined in the Kubernetes documentation. Pipelines as Code supports the specification for the OWNERS and OWNERS_ALIASES files. If the OWNERS file includes a filters section, Pipelines as Code matches approvers and reviewers only against the .* filter.

5.4.4. Advanced event matching
Link kopieren

Pipelines as Code supports by 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.

Important

If you use the on-cel-expression annotation in the same pipeline run as an on-event, on-target-branch, on-label, on-path-change, or on-path-change-ignore annotation, the on-cel-expression annotation takes priority and Pipelines as Code ignores the other annotations.

To use CEL-based filtering with Pipelines as Code, consider the following examples of annotations:

  • To match a pull_request event targeting the main branch and coming from the wip 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()
# ...
    .pathChanged()
    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 the experimental 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: A push or pull_request event.
  • target_branch: The target branch.
  • source_branch: The branch of origin of a pull_request event. For push events, it is same as the target_branch.
  • event_title: Matches the title of the event, such as the commit title for a push event, and the title of a pull or merge request for a pull_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.

Important

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"
# ...
Note

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 has 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 add a new SHA commit. To add a new SHA commit, use the following command: 

git commit --amend --no-edit && git push --force-with-lease

5.5. Annotations for filtering events matched to a pipeline run
Link kopieren

Add annotations to a pipeline run to filter events that Pipelines as Code matches, ensuring the pipeline run starts only when all annotations match the event.

You can add one or more annotations to a pipeline run to filter the events that Pipelines as Code matches to this pipeline run. In this case, when the defined matching event (such as a pull request, a push event, or a comment) happens, Pipelines as Code checks if these annotations also match. The pipeline run starts only if all the annotations that you added match the event.

5.5.1. Matching changes in paths to a pipeline run
Link kopieren

You can match a pipeline run to changes in a set of paths. Pipelines as Code starts the pipeline run only if the pull request or push event 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/**]"
# ...

5.5.2. Excluding changes in paths from matching a pipeline run
Link kopieren

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.

The following example matches the pipeline-docs-not-generated pipeline run when a pull request changes any files under the docs directory or its subdirectories. The match excludes changes that 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/**]"
# ...

5.5.3. Matching a pull request label to a pipeline run
Link kopieren

Important

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 only when the pull request has any of these labels. When you update the pull request with a new commit, if the label is still present, Pipelines as Code starts the pipeline run again.

The following example matches the pipeline-bug-or-defect pipeline run when you add the bug or defect label to a pull request. It also matches when you update a labeled pull request with a new commit: 

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: pipeline-bug-or-defect
annotations:
  pipelinesascode.tekton.dev/on-label: "[bug, defect]"
# ...
Note

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.

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, consuming excessive cluster resources.

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.
  • A user merges or closes the pull request that triggered the pipeline run.

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"
# ...
Important

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.

Note
  • 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.
  • To enable cancellation-in-progress for all default pipeline runs, use the enable-cancel-in-progress-on-pull-requests and the enable-cancel-in-progress-on-push settings. These settings are available in the platforms.openshift.pipelinesAsCode.settings spec of the TektonConfig custom resource (CR) configure Pipelines as Code.
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben