Este conteúdo não está disponível no idioma selecionado.
Chapter 1. About Pipelines as Code
With Pipelines as Code, cluster administrators and users with the required privileges can define pipeline templates as part of source code Git repositories. When triggered by a source code push or a pull request for the configured Git repository, Pipelines as Code runs the pipeline and reports the status.
1.1. Key features Copiar o linkLink copiado para a área de transferência!
Pipelines as Code supports the following features:
- Pull request status and control on the platform hosting the Git repository.
- GitHub Checks API to set the status of a pipeline run, including rechecks.
- GitHub pull request and commit events.
-
Pull request actions in comments, such as
/retest
. - Git events filtering and a separate pipeline for each event.
- Automatic task resolution in OpenShift Pipelines, including local tasks, Tekton Hub, and remote URLs.
- Retrieval of configurations using GitHub blobs and objects API.
-
Access Control List (ACL) over a GitHub organization or using a Prow style
OWNERS
file. -
The
tkn pac
CLI plugin for managing bootstrapping and Pipelines as Code repositories. - Support for GitHub App, GitHub Webhook, Bitbucket Data Center, and Bitbucket Cloud.
1.2. Pipelines as Code concepts Copiar o linkLink copiado para a área de transferência!
Pipelines as Code interacts with your Git repository provider. To use Pipelines as Code, you must first configure this integration.
You can use Pipelines as Code with any number of repositories within your Git repository provider. For each repository, you must create a Repository
custom resource (CR) within an OpenShift Container Platform namespace that you control. This CR contains information that Pipelines as Code can use to access this repository.
Pipelines as Code starts the pipeline runs for a repository within the namespace in which the Repository
CR for this repository is located.
Inside your Git repository, you must create a .tekton
directory and store pipeline run definitions as YAML files in this directory. Each pipeline run that you define must include annotations that determine the events that must trigger this pipeline run.
The definition can reference other YAML files in the same directory. For example, you can define a pipeline in a separate YAML file and refer to this pipeline in the pipeline run file. You can also use annotations in the pipeline run definition to reference task and pipeline resources from Tekton Hub, from HTTP locations, and from other paths in your directory. You can use special variables in the definition to reference execution context, such as the name of the branch.
When a matching event happens, Pipelines as Code creates a PipelineRun
CR based on the definition that you provided in the repository. Creating a PipelineRun
CR triggers execution of the pipeline that is defined in the pipeline run.
Pipelines as Code uses the Pipelines as Code resolver to create the PipelineRun
CR based on your definition. The Pipelines as Code resolver retrieves all of the resources that you referenced by using annotations and adds them to the PipelineRun
CR. If the Pipelines as Code resolver fails to retrieve any referenced resource, Pipelines as Code logs an error and does not create a pipeline run.
Pipelines as Code also replaces dynamic variables in your pipeline run definition with their values.
By default, when creating a PipelineRun
CR for a pull request or push event, Pipelines as Code uses the definitions from the .tekton
directory of the source branch of the pull request or push event. If the pull request or push event modifies the .tekton
directory, Pipelines as Code uses the modified version.
You can define the pipelinerun_provenance: "default_branch"
setting in the Repository
CR to change this behaviour. If you specify this setting, Pipelines as Code always uses definitions from the .tekton
directory of the default branch configured on the Git repository provider, such as main
, master
, or trunk
.