/docs/guide/Recent content in Usage Guide on Pipelines as CodeHugo -- gohugo.ioen-us/docs/guide/repositorycrd/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/repositorycrd/Repository CR # The Repository CR serves the following purposes: Informing Pipelines-as-Code that an event from a specific URL needs to be handled. Specifying the namespace where the PipelineRuns will be executed. Referencing an API secret, username, or API URL if necessary for Git provider platforms that require it (e.g., when using webhooks instead of the GitHub application). Providing the last PipelineRun statuses for the repository (5 by default)./docs/guide/resolver/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/resolver/Pipelines-as-Code resolver # The Pipelines-as-Code resolver ensures that the PipelineRun you are running doesn’t conflict with others. Pipelines-as-Code parses any files ending with a .yaml or .yml suffix in the .tekton directory and subdirectory at the root of your repository. It will automatically attempt to detect any Tekton resources like Pipeline, PipelineRun, Task. When detecting a PipelineRun it will try to resolve it as a single PipelineRun with an embedded PipelineSpec of the referenced Task or Pipeline./docs/guide/authoringprs/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/authoringprs/Authoring PipelineRuns in .tekton/ directory # Pipelines-as-Code will always try to be as close to the Tekton template as possible. Usually, you will write your template and save them with a .yaml extension, and Pipelines-as-Code will run them. The .tekton directory must be at the top level of the repo. You can reference YAML files in other repos using remote URLs (see Remote HTTP URLs for more information), but PipelineRuns will only be triggered by events in the repository containing the ./docs/guide/matchingevents/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/matchingevents/Matching a PipelineRun to a Git provider Event # A PipelineRun can be matched to a Git provider event by using specific annotations in the PipelineRun metadata. For example, when you have these as metadata in your PipelineRun: metadata: name: pipeline-pr-main annotations: pipelinesascode.tekton.dev/on-target-branch: "[main]" pipelinesascode.tekton.dev/on-event: "[pull_request]" Pipelines-as-Code will match the PipelineRun pipeline-pr-main if the Git provider events target the branch main and it’s coming from a [pull_request]/docs/guide/running/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/running/Running the PipelineRun # Pipelines-as-Code (PAC) can be used to run pipelines on events such as pushes or pull requests. When an event occurs, PAC will try to match it to any PipelineRuns located in the .tekton directory of your repository that are annotated with the appropriate event type. The PipelineRuns definitions are fetched from the .tekton directory at the root of your repository from where the event comes from, this is unless you have configured the provenance from the default branch on your Repository CR./docs/guide/gitops_commands/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/gitops_commands/GitOps Commands # Pipelines-as-Code supports the concept of GitOps commands, which allow users to issue special commands in a comment on a Pull Request or a pushed commit to control Pipelines-as-Code. The advantage of using a GitOps command is that it provides a journal of all the executions of your pipeline directly on your Pull Request, near your code. GitOps Commands on Pull Requests # For example, when you are on a Pull Request, you may want to restart all your PipelineRuns./docs/guide/statuses/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/statuses/Status # GitHub apps # After the PipelineRun has finished, its status will be shown in the GitHub Check tabs, along with a concise overview of the status the name and the duration of each task in the pipeline. If the task has a displayName it will use it as the description of the task or otherwise just the task name. If any step fails, a small portion of the log from that step will also be included in the output./docs/guide/privaterepo/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/privaterepo/Private repositories # Pipelines-as-Code allows the use of private repositories by creating or updating a secret in the target namespace. This secret contains the user token required for the git-clone task to clone private repositories. Whenever Pipelines-as-Code creates a new PipelineRun in the target namespace, it also creates a secret with a specific name format: pac-gitauth-REPOSITORY_OWNER-REPOSITORY_NAME-RANDOM_STRING This secret contains a Git Config file named .gitconfig and a Git credentials file named ./docs/guide/cleanups/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/cleanups/PipelineRuns Cleanups # There can be many PipelineRuns into a user namespace and Pipelines-as-Code has the ability to only keep a certain amount of PipelineRuns and cleaning the old ones. When your PipelineRun has this annotation : pipelinesascode.tekton.dev/max-keep-runs: "maxNumber" Pipelines-as-Code sees this and will start cleaning up right after one of the PipelineRun finishes to a successful execution keeping only the last maxNumber of PipelineRuns. It will skip the Running or Pending PipelineRuns but will not skip the PipelineRuns with Unknown status./docs/guide/customparams/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/customparams/Custom Parameters # Using the {{ param }} syntax, Pipelines-as-Code lets you expand a variable or the payload body inside a template within your PipelineRun. By default, several variables are exposed according to the event. To view all the variables exposed by default, refer to the documentation on Authoring PipelineRuns. With the custom parameter, you can specify some custom values to be replaced inside the template. Utilizing the Tekton PipelineRun parameters feature may generally be the preferable approach, and custom params expansion should only be used in specific scenarios where Tekton params cannot be used./docs/guide/incoming_webhook/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/incoming_webhook/Incoming webhook # Pipelines-as-Code support the concept of incoming webhook URL. It let you trigger PipelineRun in a Repository using a shared secret and URL, instead of creating a new code iteration. Incoming Webhook URL # To use incoming webhooks in Pipelines-as-Code, you must configure the incoming field in your Repository CRD. This field references a Secret, which serves as the shared secret, as well as the branches targeted by the incoming webhook./docs/guide/policy/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/policy/Policy on Pipelines-as-Code Actions # Pipelines-as-Code uses policies to control which actions can be performed by users who belong to specific teams within an organization, as defined on GitHub or other supported Git providers (currently GitHub and Gitea). This feature is supported on the following providers Git Provider Supported GitHub App ✅️ GitHub Webhook ✅️ Gitea ✅️ GitLab ❌️ Bitbucket Cloud ❌️ Bitbucket Data Center ❌️ Supported Actions # pull_request - This action triggers the CI in Pipelines-as-Code./docs/guide/cli/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/cli/Pipelines-as-Code CLI # Pipelines-as-Code provides a powerful CLI designed to work as a plug-in to the Tekton CLI (tkn). tkn pac allows you to: bootstrap: quickly bootstrap a Pipelines-as-Code installation. create: create a new Pipelines-as-Code Repository definition. delete: delete an existing Pipelines-as-Code Repository definition. generate: generate a simple pipelinerun to get you started with Pipelines-as-Code. list: list Pipelines-as-Code Repositories. logs: show the logs of a PipelineRun from a Repository CRD.