Story (Required)

As a Pipelines-as-Code user, when an `/incoming` request is made for a GitLab repository with an invalid Personal Access Token (PAT), I want the PAC controller to handle the authentication error gracefully and log it, instead of panicking and crashing.

This story addresses a controller panic that impacts service reliability. When misconfigured credentials are used for GitLab, the controller enters an unhandled error state and crashes with a nil pointer dereference. This improves the customer experience by making the controller more resilient to configuration errors and providing clear, actionable feedback in the logs.

Background (Required)

A customer using OpenShift Pipelines `1.16.4` reported that the Pipelines-as-Code (PAC) controller pod crashes with a `panic: runtime error: invalid memory address or nil pointer dereference`. The crash was observed to happen reliably when sending a `POST` request to the `/incoming` endpoint for a repository configured with a GitLab provider.

Investigation revealed that the root cause is an incorrectly configured `provider.token` (PAT) in the secret used by the `Repository` CR. When the PAC controller receives the request, it attempts to connect to GitLab using the invalid credentials. The resulting authentication error is not handled correctly, which leads to a panic and container restart.

This issue has been reproduced on newer versions of pipelines (`1.19.3`), confirming it is an existing bug.

Replication Steps:
1. Configure a `Repository` CR for a GitLab provider.
2. In the corresponding secret, provide an invalid value for the `provider.token` key.
3. Send a `POST` request to the PAC controller's `/incoming` endpoint to trigger a `PipelineRun` for that repository.
4. Observe that the PAC controller pod panics and restarts.

Panic Log:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x1f53758]

goroutine 10919 [running]:
github.com/openshift-pipelines/pipelines-as-code/pkg/events.(*EventEmitter).EmitMessage(0xc000a050e0?, 0x2d08333?, 0x40?, {0x2cb8132?, 0x0?}, {0xc000d4ec30?, 0x0?})
	/go/src/github.com/openshift-pipelines/pipelines-as-code/pkg/events/emit.go:46 +0x298
github.com/openshift-pipelines/pipelines-as-code/pkg/provider/gitlab.(*Provider).CreateStatus(0xc0003dc3f0, {0x0?, 0xc00083fcb0?}, 0xc0008a4a80, {0x0, {0x0, 0x0}, {0x0, 0x0}, {0x2c9af3c, ...}, ...})
	/go/src/github.com/openshift-pipelines/pipelines-as-code/pkg/provider/gitlab/gitlab.go:290 +0x745
github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode.(*PacRun).Run(0xc000941e00, {0x30b8f78, 0xc00016d1d0})
	/go/src/github.com/openshift-pipelines/pipelines-as-code/pkg/pipelineascode/pipelineascode.go:67 +0x252
github.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*sinker).processEvent(0xc000556120, {0x30b8f78, 0xc00016d1d0}, 0xc0004157c0?)
	/go/src/github.com/openshift-pipelines/pipelines-as-code/pkg/adapter/sinker.go:60 +0x3a8
github.com/openshift-pipelines/pipelines-as-code/pkg/adapter.(*listener).Start.listener.handleEvent.func2.1()
	/go/src/github.com/openshift-pipelines/pipelines-as-code/pkg/adapter/adapter.go:206 +0x2c

Out of scope

• Fixing similar issues for other Git providers (e.g., BitBucket, GitHub), unless the fix is inherently generic.
• Proactive validation of provider tokens outside of an API request context.

Approach (Required)

The stack trace points to a failure in `pkg/provider/gitlab/gitlab.go:290` within the `CreateStatus` function, which then leads to a panic in `pkg/events/emit.go:46` when trying to use a nil logger.

The fix will involve adding proper error handling in the GitLab provider code.
1. After attempting to create a GitLab client or perform an action that requires authentication, check for authentication-related errors.
2. If an authentication error is detected, the function should stop execution for the current request.
3. It should log a descriptive error message, such as "Failed to authenticate to GitLab for repository <repo_name>: please check the provider.token".
4. The function must return the error gracefully instead of proceeding, which will prevent the panic from occurring. This ensures the controller remains stable and provides clear feedback for debugging user configuration issues.

Dependencies

• None. This is a self-contained fix within the Pipelines-as-Code controller.

Acceptance Criteria (Mandatory)

GIVEN a `Repository` CR is configured for a GitLab provider
AND the secret referenced by the `Repository` contains an invalid `provider.token`
WHEN a `POST` request is sent to the `/incoming` endpoint for that repository
THEN the Pipelines-as-Code controller pod must not crash or restart.
AND the controller logs must contain a clear error message indicating an authentication failure with GitLab.
AND an appropriate `Event` should be emitted on the `Repository` object detailing the configuration error.
AND no `PipelineRun` should be created.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• [ ] Code is completed, reviewed, documented and checked in
• [ ] Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• [ ] Continuous Delivery pipeline(s) is able to proceed with new code included
• [ ] Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• [ ] Acceptance criteria are met