Global repository settings is a Technology Preview feature only. Technology Preview features are not currently supported and might not be functionally complete. We do not recommend using them in production. These features provide early access to an upcoming Pipelines-as-Code features, enabling you to test functionality and provide feedback during the development process.
Pipelines-as-Code Global Repository Settings #
Pipelines-as-Code lets you have a global repository for settings of all your local repositories. This enables you to define settings that will be applied to all local repositories on your cluster.
The global repository settings serve as a fallback for all repositories if the local repository settings in the namespace do not override them.
The global repository must be created in the namespace where the
pipelines-as-code
controller is installed (usually pipelines-as-code
or
openshift-pipelines
).
The global repository Custom Resource (CR) does not need a spec.url
field. The
field can either be blank or point to an unknown destination, such as:
By default, the global repository should be named pipelines-as-code
unless
you redefine it by setting the environment variable
PAC_CONTROLLER_GLOBAL_REPOSITORY
in the controller and watcher Deployment.
The settings that can be defined in the global repository are:
- Concurrency Limit.
- PipelineRun Provenance.
- Repository Policy.
- Repository GitHub App Token Scope.
- Git provider auth settings such as user, token, URL, etc.
- The
type
must be defined in the namespace repository settings and must match thetype
of the global repository (see below for an example).
- The
- Custom Parameters.
- Incoming Webhooks Rules.
Global settings are only applied when running via a Git provider event; they are not applied when for example using the tkn pac
cli.
Example of How Global Repository Settings Are Applied #
- If you have a Repository CR in the namespace named
user-namespace
:
apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
name: repo
namespace: user-namespace
spec:
url: "https://my.git.com"
concurrency_limit: 2
git_provider:
type: gitlab
- And a global Repository CR in the namespace where the controller and the watcher is located:
apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
name: pipelines-as-code
namespace: pipelines-as-code
spec:
url: "https://paac.repo"
concurrency_limit: 1
params:
- name: custom
value: "value"
git_provider:
type: gitlab
secret:
name: "gitlab-token"
webhook_secret:
name: gitlab-webhook-secret
In this example, the Repository repo
will have a concurrency limit of 2 since
the setting comes from the user namespace and is ignored from the global
repository. The parameter custom
will be set to value
and will be available
for every repository that does not define other custom parameters.
Since the local Repository CR has the git_provider.type
set to gitlab
, like
the global Repository CR, the Git provider settings for GitLab
will be taken from the global repository. The secret referenced will be fetched
from where the global repository is defined.
Webhook Based provider global settings #
These are the spec.git_provider.type
you can set up for the Git provider
settings. They are only used when handling incoming webhooks or global
repository settings. They are used for webhook-based Git providers (i.e.,
everything except GitHub Apps installations). In this case, the type github
means a repository configured using GitHub webhooks:
- github
- gitlab
- gitea
- bitbucket-cloud
- bitbucket-server
The global repository settings for the Git provider can currently only reference one type of provider on a cluster. The user would need to specify their own provider information in their own Repository CR if they do not want to use the global settings or want to target another provider.