When Pipelines as Code checks permissions on GitHub, a repository that does not have an OWNERS file can still produce an error log that looks like a real failure.
This is confusing because the check actually continues normally, but the controller log still says GitHub API call failed.
Expected behavior:
- Missing
OWNERS should not look like a controller failure
- The logs should stay quiet or use a lower log level for this normal case
Why this matters:
- Operators may think GitHub access is broken when it is not
- Normal repositories without
OWNERS create noisy and misleading logs
snazyed error
🚨 07:52:23 pac-controller GitHub API call failed repo=pipelines-as-code-ci/tektoncd-pipelines-as-code-ci
────────────────────────────────────────────────────────────────────────────────
Stacktrace:
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.(*Provider).logAPICall
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/profiler.go:130
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.wrapAPIGetContents
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/profiler.go:147
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.(*Provider).GetFileInsideRepo
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/github.go:480
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.(*Provider).getFileFromDefaultBranch
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/acl.go:302
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.(*Provider).IsAllowedOwnersFile
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/acl.go:65
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.(*Provider).aclCheckAll
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/acl.go:238
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github.(*Provider).IsAllowed
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/github/acl.go:99
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode.(*PacRun).checkAccessOrError
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode/errors.go:25
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode.(*PacRun).verifyRepoAndUser
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode/match.go:121
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode.(*PacRun).matchRepoPR
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode/match.go:28
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode.(*PacRun).Run
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode/pipelineascode.go:83
github.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*sinker).processEvent
github.com/openshift-pipelines/pipelines-as-code/pkg/adapter/sinker.go:121
github.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*listener).Start.listener.handleEvent.func2.1
github.com/openshift-pipelines/pipelines-as-code/pkg/adapter/adapter.go:209
────────────────────────────────────────────────────────────────────────────────
When Pipelines as Code checks permissions on GitHub, a repository that does not have an
OWNERSfile can still produce an error log that looks like a real failure.This is confusing because the check actually continues normally, but the controller log still says
GitHub API call failed.Expected behavior:
OWNERSshould not look like a controller failureWhy this matters:
OWNERScreate noisy and misleading logssnazyed error