ConfigMap Reference

Sets the application name that Pipelines-as-Code displays in status updates and comments. If you use the GitHub App, also customize this label in the GitHub App settings.

application-name: "Pipelines as Code CI"

Controls whether Pipelines-as-Code automatically creates a secret containing the Git provider token for use by the git-clone task.

secret-auto-create: "true"

Controls whether Pipelines-as-Code scopes generated tokens to only the repository that triggered the event. This setting is important when the GitHub App is installed on an organization with a mix of public and private repositories where some users should not access all repositories. Set to false if you trust every user in your organization to access all repositories, or if you are not installing your GitHub App at the organization level.

secret-github-app-token-scoped: "true"

Adds extra repositories to the token scope without disabling scoping entirely. List additional owner/repo pairs (on the same installation ID), separated by commas. Use this when your pipeline needs to access a shared library or dependency repository.

secret-github-app-scope-extra-repos: "owner/private-repo1, org/repo2"

Specifies the default hub API URL that Pipelines-as-Code uses to fetch remote tasks.

hub-url: "https://artifacthub.io"

Configures additional hub catalogs. You can define multiple catalogs by incrementing the number (catalog-1-, catalog-2-, etc.).

catalog-1-id: "custom"
catalog-1-name: "tekton"
catalog-1-url: "https://api.custom.hub"

Controls whether Pipelines-as-Code fetches remote tasks from configured hubs.

remote-tasks: "true"

Sets the Tekton dashboard URL. Pipelines-as-Code uses this base URL to generate links to PipelineRun details in status reports.

tekton-dashboard-url: "https://tekton.example.com"

Sets the display name for a custom console to use instead of the Tekton dashboard.

custom-console-name: "Console Name"

Sets the base URL of the custom console.

custom-console-url: "https://url"

Defines the template URL for PipelineRun details. Supports variables: {{ namespace }}, {{ pr }}.

custom-console-url-pr-details: "https://url/ns/{{ namespace }}/{{ pr }}"

Defines the template URL for task logs. Supports variables: {{ namespace }}, {{ pr }}, {{ task }}.

custom-console-url-pr-tasklog: "https://url/ns/{{ namespace }}/{{ pr }}/logs/{{ task }}"

Defines the template URL for namespace-level views in your custom console. Supports the {{ namespace }} variable.

custom-console-url-namespace: "https://url/ns/{{ namespace }}"

Controls whether Pipelines-as-Code shows a log snippet from the failed task when a Pipeline encounters an error. Disable this setting if your pipeline output may contain sensitive values.

error-log-snippet: "true"

Sets the number of lines to display in error log snippets when error-log-snippet is true. Keep this value conservative because the GitHub Check interface has a 65,535 character limit.

error-log-snippet-number-of-lines: "3"

Controls whether Pipelines-as-Code inspects container logs to detect error messages and exposes them as annotations on pull requests. Only GitHub Apps are supported.

error-detection-from-container-logs: "true"

Sets how many lines Pipelines-as-Code reads from the container when inspecting logs for error detection. Increasing this value may increase watcher memory usage. Use -1 for unlimited lines.

error-detection-max-number-of-lines: "50"

Sets the default regular expression used for simple error detection. Must be a valid regular expression.

error-detection-simple-regexp: |
  ^(?P<filename>[^:]*):(?P<line>[0-9]+):(?P<column>[0-9]+)?([ ]*)?(?P<error>.*)

Controls whether Pipelines-as-Code automatically cancels in-progress PipelineRuns for a pull request when that pull request receives a new push. This prevents redundant runs from consuming cluster resources.

enable-cancel-in-progress-on-pull-requests: "false"

Controls whether Pipelines-as-Code automatically cancels in-progress PipelineRuns triggered by a push event when a new push occurs on the same branch. This prevents overlapping runs for the same branch.

enable-cancel-in-progress-on-push: "false"

Controls whether Pipelines-as-Code validates incoming webhook requests against Bitbucket Cloud’s published IP ranges at https://ip-ranges.atlassian.com/. Because public Bitbucket does not support webhook secrets, IP verification is the primary security mechanism. This check applies only to public Bitbucket (when provider.url is not set in the Repository CR spec).

Disabling this setting creates a security risk. A malicious user could submit a pull request with a modified PipelineRun that exfiltrates secrets, then send a forged webhook payload to trigger it.

bitbucket-cloud-check-source-ip: "true"

Adds extra IPs (for example, 127.0.0.1) or networks (for example, 127.0.0.0/16) to the allowed list, separated by commas.

bitbucket-cloud-additional-source-ip: "192.168.1.0/24, 10.0.0.1"

Sets the maximum value that a user can specify in the max-keep-run annotation on a PipelineRun. If a user sets a value higher than this limit, Pipelines-as-Code uses the upper limit during cleanup instead.

max-keep-run-upper-limit: "100"

Sets the default cleanup retention count. Pipelines-as-Code applies this value to all PipelineRuns that do not have the max-keep-runs annotation.

default-max-keep-runs: "10"

Controls whether Pipelines-as-Code automatically creates a namespace and Repository CR for newly created repositories. Supported only with the GitHub App.

auto-configure-new-github-repo: "false"

Defines the template for generating namespace names when auto-configuring GitHub repositories. Supported fields: {{repo_owner}}, {{repo_name}}.

auto-configure-repo-namespace-template: "{{repo_owner}}-{{repo_name}}"

Defines the template for generating Repository CR names when auto-configuring GitHub repositories. Supported fields: {{repo_owner}}, {{repo_name}}.

auto-configure-repo-repository-template: "{{repo_owner}}-{{repo_name}}-repo-cr"

Comma-separated list of Git provider hostnames that Pipelines-as-Code is allowed to send credentials to.

Pipelines-as-Code derives the provider API host it talks to from webhook data. This allowlist makes sure a crafted payload cannot redirect the controller, and its credentials, to a host an attacker controls.

The key has two states:

• Controller managed (the key is empty): the public hostnames github.com, gitlab.com, bitbucket.org, gitea.com and codeberg.org stay trusted, any other host is refused, and every request the provider itself authenticated adds its hostname to the pipelinesascode.tekton.dev/auto-trusted-provider-hostnames annotation. A default installation therefore needs no configuration, and a controller serving several instances learns all of them.
• Administrator configured (the key is non-empty): the list is authoritative for every hostname, public ones included, and the controller stops learning hosts. Listing only ghe.example.com is how an administrator says “this controller must never talk to a public SaaS instance”.

The configuration key belongs only to administrators; the annotation belongs only to the controller. Keeping them separate makes the policy mode unambiguous even when both contain the same hostname.

A hostname that is not routable on the public internet (loopback, link-local, a private range, or an in-cluster .svc name) is never recorded automatically, since a payload must not be able to point the controller at the cloud metadata endpoint or an internal service. List it explicitly to trust it.

Paths that carry no provider signature, such as incoming webhooks, never record a hostname, so set this key explicitly on any self-hosted instance.

A value holding only whitespace or separators counts as unset, so use a real hostname rather than a placeholder when you mean to configure the policy.

Removing a hostname from a non-empty list immediately narrows the policy. Emptying the key returns to controller-managed mode, where previously learned hosts become effective again. To return to a clean managed policy, empty the key and delete the pipelinesascode.tekton.dev/auto-trusted-provider-hostnames annotation.

Today the allowlist gates the GitHub provider; the other providers are being moved onto it.

Each controller has its own ConfigMap and therefore its own allowlist.

trusted-provider-hostnames: "ghe.example.com, gitlab.example.com"

Controls whether Pipelines-as-Code remembers a previous /ok-to-test approval when new commits are pushed to a pull request. By default, users must issue /ok-to-test on each push. Set to true to persist the approval across push events.

remember-ok-to-test: "false"

Requires that a pull request’s commit SHA be specified in an /ok-to-test comment. This prevents a race condition where a malicious user pushes a new commit after the /ok-to-test comment but before Pipelines-as-Code starts the CI run.

require-ok-to-test-sha: "false"

Prevents duplicate PipelineRuns when a commit appears in both a push event and a pull request. When a push event arrives from a commit that belongs to an open pull request, Pipelines-as-Code skips the push event.

skip-push-event-for-pr-commits: "true"

Enables retrying GitHub and GitLab API requests when Pipelines-as-Code encounters a temporary provider failure. This includes rate limits, temporary server errors, and selected network failures.

Retries use backoff with jitter so multiple requests do not all retry at the same time. When the provider supplies a retry or reset time, Pipelines-as-Code uses that information as long as it does not exceed api-retry-max-wait-seconds.

The setting is disabled by default. Enabling it affects API operations made while processing an event, including temporary clients and GitHub App setup.

When disabled, the GitLab client keeps the retry behaviour built into the upstream GitLab Go client, and the GitHub client performs no retries.

Pipelines-as-Code only repeats an operation when it can do so safely. It does not repeat provider changes after an uncertain network or server failure when doing so could create duplicate comments, statuses, or other mutations.

Independently of this setting, Pipelines-as-Code always retries a GitHub check-run update that returns a 404 when the check-run id comes from the annotation on a PipelineRun. Another reconcile may have created that check run moments earlier and GitHub can still report it as missing, so the update is retried a few times with a short backoff before the error is reported.

enable-api-retry: "false"

Sets the maximum number of attempts when enable-api-retry is true. The initial request counts as the first attempt. For example, a value of 4 allows the initial request followed by up to three retries.

api-retry-max-attempts: "4"

Sets the maximum time in seconds that Pipelines-as-Code waits between attempts. If a provider asks the client to wait longer than this value, Pipelines-as-Code stops retrying rather than holding the event for a long cooling period.

api-retry-max-wait-seconds: "120"