Pipelines-As-Code configuration settings #
There is a few things you can configure through the config map
pipelines-as-code
in the pipelines-as-code
namespace.
application-name
The name of the application showing for example in the GitHub Checks labels. Default to
Pipelines as Code CI
secret-auto-create
Whether to auto create a secret with the token generated through the GitHub application to be used with private repositories. This feature is enabled by default.
secret-github-app-token-scoped
When using a Github app,
Pipelines as Code
will generate a temporary installation token for every allowed event coming through the controller.The generated token will be scoped to the repository from the repository where the payload come from and not to every repositories the app installation has access to.
Having access to every repositories the app has access to is a problem when you install the
Pipelines as Code
application into an organization that has a mixed between public and private repositories where every users in the organization is not trusted to have access to the private repositores. Since the scoping of the token only allow the user do operations and access on the repository where the payload come from, it will not be able to access the private repos.However, if you trust every users of your organization to access any repositories or you are not planning to install your GitHub app globally on a GitHub organization, then you can safely set this option to false.
secret-github-app-scope-extra-repos
If you don’t want to completely disable the scoping of the token, but still wants some other repos available (as long you have installed the github app on it), then you can add an extra owner/repo here.
This let you able fetch remote url on github from extra private repositories in an organisation if you need it.
This only works when all the repos are added from the same installation IDs.
You can have multiple owner/repository separated by commas:
secret-github-app-token-scoped: "owner/private-repo1, org/repo2"
remote-tasks
This allows fetching remote tasks on pipelinerun annotations. This feature is enabled by default.
hub-url
The base URL for the tekton hub API. This default to the public hub: https://api.hub.tekton.dev/v1
hub-catalog-name
The tekton hub catalog name. default to
tekton
bitbucket-cloud-check-source-ip
Public bitbucket doesn’t have the concept of Secret, we need to be able to secure the request by querying atlassian ip ranges, this only happen for public bitbucket (ie: when provider URL is not set in repository spec). If you want to override this, you need to bear in mind this could be a security issue, a malicious user can send a PR to your repo with a modification to your PipelineRun that would grab secrets, tunnel or others and then send a malicious webhook payload to the controller which look like a authorized owner has send the PR to run it. This feature is enabled by default.
bitbucket-cloud-additional-source-ip
Let you add extra IPS to allow bitbucket clouds, you can do a specific IP:
127.0.0.1
or a networks127.0.0.0/16
. Multile of them can be specified separated by commas.max-keep-run-upper-limit
This let the user define a max limit for the max-keep-run value. When the user has defined a max-keep-run annotation on a pipelineRun then its value should be less than or equal to the upper limit, otherwise upper limit will be used for cleanup.
default-max-keep-runs
This let the user define a default limit for the
max-keep-run
value. When defined it will applied to all the pipelineRun without amax-keep-runs
annotation.auto-configure-new-github-repo
This setting let you autoconfigure newly created GitHub repositories. When Pipelines as Code sees a new repository URL from a payload, It Code will set up a namespace for your repository and create a Repository CR.
This feature is disabled by default and is only supported with GitHub App.
If you have a GitHub App already setup then verify if the repository
event is
subscribed into your Github App setting.
auto-configure-repo-namespace-template
If
auto-configure-new-github-repo
is enabled then you can provide a template for generating the namespace for your new repository. By default, the namespace will be generated using this format{{repo_name}}-pipelines
.You can override the default using the following variables
{{repo_owner}}
: The repository owner.{{repo_name}}
: The repository name.
For example. if the template is defined as
{{repo_owner}}-{{repo_name}}-ci
, then the namespace generated for repositoryhttps://github.com/owner/repo
will beowner-repo-ci
Error Detection #
Pipelines as Code can show a snippet and optionally detect the error in the pipelinerun logs, you can configure the behaviour with these settings:
error-log-snippet
Enable or disable the feature to show a log snippet of the failed task when there is an error in a PipelineRun.
Due of the constraint of the different GIT provider API, It will show the last 3 lines of the first container from the first task that has exited with an error in the PipelineRun.
If it find any strings matching the values of secrets attached to the PipelineRun it will replace it with the placeholder
******
error-log-snippet
{{ hint danger }} alpha feature: may change at any time {{ /hint danger }}
Enable or disable the inspection of container logs to detect error message and expose them as annotations on Pull Request. Only Github apps is supported.
error-detection-max-number-of-lines
{{ hint danger }} alpha feature: may change at any time {{ /hint danger }}
How many lines to grab from the container when inspecting the
logs for error detection when using error-log-snippet
. Increasing this value
may increase the watcher memory usage. The default is 50, increase this value
or use -1 for unlimited.
error-detection-simple-regexp
{{ hint danger }} alpha feature: may change at any time {{ /hint danger }}
By default error detection only support the simple outputs, the way GCC or make will output which is supported by most linters and command line tools.
An example is :
test.js:100:10: an error occurred
Pipelines as Code will see this line and show it as an annotation on the pull request where the error occurred.
You can configure the default regexp used for detection. You will need to
keep the regexp groups: <filename>
, <line>
, <error>
to make it works.
Reporting logs URL to Tekton Dashboard or custom Console #
Pipelines as Code have the ability to automatically detect the OpenShift Console and link the logs of the tasks to the
public URL of the OpenShift Console. If you are using the Tekton Dashboard, you can configure this feature using the
tekton-dashboard-url
setting. Simply set this to your dashboard URL, and the pipelinerun status and tasklog will be
displayed there.
Alternatively, you can also configure a custom console with the following settings:
custom-console-name
Set this to the name of your custom console. example: MyCorp Console
custom-console-url
Set this to the root URL of your custom console. example: https://mycorp.com
custom-console-url-pr-details
Set this to the URL where to view the details of the PipelineRun
. This is
shown when the PipelineRun is started so the user can follow execution on your
console or when to see more details about the pipelinerun ion result.
The URL suports templating for these value:
{{ namespace }}
: The target namespace where the pipelinerun is executed{{ pr }}
: The PipelineRun name.
example: https://mycorp.com/ns/{{ namespace }}/pipelienrun/{{ pr }}
custom-console-url-pr-tasklog
Set this to the URL where to view the log of the taskrun of the PipelineRun
. This is
shown when we post a result of the task breakdown to link to the logs of the taskrun.
The URL suports templating for these value:
{{ namespace }}
: The target namespace where the pipelinerun is executed{{ pr }}
: The PipelineRun name.{{ task }}
: The Task name in the PR{{ pod }}
: The Pod name of the TaskRun{{ firstFailedStep }}
: The name of the first failed step in the TaskRun
example: https://mycorp.com/ns/{{ namespace }}/pipelinerun/{{ pr }}/logs/{{ task }}#{{ pod }}-{{ firstFailedStep }}
Pipelines-As-Code Info #
There are a settings exposed through a config map for which any authenticated user can access to know about the Pipeline as Code status.
version
The version of Pipelines As Code currently installed.
controller-url
The controller URL as set by the
tkn pac bootstrap
command while setting up the GitHub App or if Pipelines as code is installedThe OpenShift Pipelines Operator will automatically set the the route created for the controller.
This field is also used to detect the controller URL when using the
tkn pac webhook add
commands.provider
The provider set to
GitHub App
by tkn pac bootstrap, used to detect if a GitHub App is already configured when a user runs the bootstrap command a second time or thewebhook add
command.