Forgejo - User %s is not allowed to trigger CI via pull_request on this repo.

[wouterhummelink]

I'm experimenting with Pipelines as Code using Forgejo/Gitea as git repository. Any attempt to trigger the pipeline results in error that I'm not allowed to trigger the pipeline. It does trigger for push to main. There are two users in the forgejo instance: whummelink (member of both owners and privatcloud) and a bot account which is member of a CI team with access to all repositories.

{"level":"info","ts":"2025-05-26T09:59:07.083Z","logger":"pipelinesascode","caller":"events/emit.go:48","msg":"policy check: retest, user: whummelink is not a member of any of the allowed teams: [owners privatcloud]","commit":"d5a550a-dirty","provider":"gitea","event-id":"ad709951-b198-4415-acec-6759f553754a","event-sha":"","event-type":"test-all-comment","namespace":"demo"}
{"level":"info","ts":"2025-05-26T09:59:07.089Z","logger":"pipelinesascode","caller":"events/emit.go:48","msg":"User whummelink is not allowed to trigger CI via pull_request on this repo.","commit":"d5a550a-dirty","provider":"gitea","event-id":"ad709951-b198-4415-acec-6759f553754a","event-sha":"","event-type":"test-all-comment","namespace":"demo"}

I have the following repository config:

apiVersion: pipelinesascode.tekton.dev/v1alpha1
kind: Repository
metadata:
  name: git-test-pipelines-as-code-git
  namespace: demo
spec:
  git_provider:
    secret:
      key: provider.token
      name: git-test-pipelines-as-code-git-token-6ttfq
    url: 'https://forgejo-http-default.apps.example.com'
    webhook_secret:
      key: webhook.secret
      name: git-test-pipelines-as-code-git-token-6ttfq
  settings:
    policy:
      ok_to_test:
        - owners
        - privatcloud
      pull_request:
        - owners
        - privatcloud
  url: 'https://forgejo-http-default.apps.example.com/privatcloud/test-pipelines-as-code'

And pipelinerun:

---
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  annotations:
    pipelinesascode.tekton.dev/on-event: "[pull_request,pull_request_comment,push]"
    pipelinesascode.tekton.dev/on-target-branch: "[main]"
    pipelinesascode.tekton.dev/on-source-branch: "[feature/*]"
  labels:
    pipelinesascode.tekton.dev/owner: whummelink
  name: test-pipelines-as-code
spec:
  serviceAccountName: default
  params:
    - name: GO_VERSION
      value: "1.24.3"
    - name: GIT_REPOSITORY_URL
      value: "{{repo_url}}"
    - name: GIT_REVISION
      value: "{{revision}}"
  pipelineSpec:
    params: 
      - name: GO_VERSION
      - name: GIT_REPOSITORY_URL
      - name: GIT_REVISION
    tasks:
      - name: fetch-repo
        taskRef:
          params:
            - name: kind
              value: task
            - name: name
              value: git-clone
            - name: namespace
              value: openshift-pipelines
          resolver: cluster
        params:
        - name: URL
          value: $(params.GIT_REPOSITORY_URL)
        - name: REVISION
          value: $(params.GIT_REVISION)
        - name: DEPTH
          value: '0'
        workspaces:
          - name: output
            workspace: source
    workspaces:
    - name: source
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 1Gi
    - name: basic-auth
      secret:
        secretName: gitlab-token

[chmouel]

this is weird because our e2e tests explicitely test this https://github.com/chmouel/pipelines-as-code/blob/main/test/gitea_access_control_test.go#L77-L82

[wouterhummelink]

I'm not using a fork to create a pull request, if that matters. As I understand it, I shouldn't even need to use the policy since I own the organization the repo is in. I've enabled debug logging, but the gitea acl code doesn't seem to log anything extra at debug level, so I have very little idea what's going on. I do see pipelinesascode pushing comments stating the failure, so it's definately not an auth issue.

[chmouel]

can you remove the policy part from you repo cr and see how it goes?

[wouterhummelink]

I started out without the policy, and added it when that didn't work.. I've in the mean time added an OWNERS file , which does seem to work.