Policy on actions
This page explains how to restrict which users can trigger pipelines or approve pull requests for CI. Use policies when you need fine-grained control over who can start PipelineRuns beyond the default collaborator and owner checks.
Overview
Pipelines-as-Code uses policies to control which actions specific team members can perform within an organization. You configure these policies in the Repository CR, referencing team names defined on your Git provider (currently GitHub and Forgejo).
This feature is supported on the following providers:
| Git Provider | Supported |
|---|---|
| GitHub App | ✅ |
| GitHub Webhook | ✅ |
| Forgejo | ✅ |
| GitLab | ❌ |
| Bitbucket Cloud | ❌ |
| Bitbucket Data Center | ❌ |
Supported actions
pull_request– Controls who can trigger CI on their own pull requests. When you specify a team, only members of that team can trigger CI, regardless of whether they are repository or organization owners or collaborators. Members listed in theOWNERSfile can still trigger CI.ok_to_test– Controls who can authorize CI for external contributors by commenting/ok-to-teston a pull request. This also applies to/testand/retestcommands. Note that/retestonly re-triggers failed PipelineRuns. This action takes precedence over thepull_requestaction.
Configuring policies in the Repository CR
To set up policies, add a settings.policy block to your Repository CR:
apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
name: repository1
spec:
url: "https://github.com/org/repo"
settings:
policy:
ok_to_test:
- ci-admins
pull_request:
- ci-usersIn this example:
- Members of the
ci-adminsteam can authorize other users to run the CI on pull requests. - Members of the
ci-usersteam can run CI on their own pull requests.