View as Markdown

Trigger Policies

Control who can trigger automation on your repositories.

Overview

Trigger policies determine:

  • Who can mention @forkline to create tasks
  • Who can trigger automation on your repositories
  • Who can run commands such as /reset-ci-auto-fix

Info: Without trigger policies, anyone who can comment on your repository could trigger automation.

Note: On GitLab and Forgejo, trigger policies apply to the repositories registered under the connector that received the webhook. Each owner adds their own webhook; a collaborator without a webhook of their own cannot trigger tasks through another owner’s webhook, whatever that owner’s policy says.

Policy Types

Policy Who Can Trigger Best For
Owner only Only you Personal repositories
Collaborators Users with write access Shared repositories
Allowlist Specific usernames Controlled access
Anyone All users Open source

Trigger Policy dropdown

Owner Only

Only the repository owner can trigger automation.

Collaborators (Default)

The person who performs the action must have write access. That is the person who writes the comment or description, assigns, requests a review or adds a label. For an assignment, a review request or a label, it is not the author of the pull request or issue.

Write access means the write, maintain or admin role on GitHub. On Forgejo and Gitea, it means direct repository collaborators and members of the owning organization (the connector token needs the read:organization scope for org members; without it only direct collaborators are allowed). The token account must itself belong to the repository-owning organization: read:organization alone does not reveal private memberships of other organizations, and Forgejo may redirect to public memberships only, leaving private org members unrecognized. Forgejo does not expose per-user effective repo permission to non-admin tokens, so org membership is used as the trust boundary. On GitLab it means the Developer role (access level 30) or higher, including access inherited from parent groups. The connector owner and Forkline’s own automation account are always allowed.

If Forkline cannot check access, because the provider is unreachable or answers with an error, it denies the request. The answer is not remembered, so the next event checks again. Comment again to retry.

Forkline remembers each access answer for 5 minutes. After you change someone’s access on the provider, it can take up to 5 minutes to apply.

Allowlist

Only specified usernames can trigger automation.

Anyone

Any user who can comment can trigger automation.

Warning: This policy allows anyone to trigger automation. Use with caution on public repositories.

Configuring Policies

  1. Navigate to Repositories
  2. Find your repository
  3. Click Settings on the repository card
  4. In the modal, find Trigger Policy
  5. Select the policy
  6. If allowlist, add usernames
  7. Click Save

Granularity Debt

On Forgejo and Gitea, org membership is coarser than write access: a read-only team member of the owning organization passes the collaborators check. This is because Forgejo does not expose per-user effective repository permission to non-admin tokens. When the B2B layer is built, per-repository granular configuration will be added (e.g. an include-org-members toggle and/or team-level permission checks).

Next Steps