ralphbean
commented
3 months ago I just saw a different instance of this tonight in https://github.com/ansible/ansible-ai-connect-service/pull/1240.
There, the user had an invalid pipelinerun (their task had runAftter: mytask instead of runAfter: [mytask]). PaC failed in its controller logs with: tekton validation error: json: cannot unmarshal string into Go struct field PipelineTask.spec.pipelineSpec.tasks.runAfter of type []string, but the user had no idea. They just assumed PaC was broken because they got no feedback on the PR.
We have a scenario where users are submitting merge requests to a gitlab repo (correctly enrolled with PaC) from a private fork that PaC doesn't have access to with its token. PaC sees the merge request event, but cannot access the private fork to retrieve the pipelienrun definition - and it fails. It will emit errors in its controller logs about this, but the end user doesn't see this. It looks like silence from PaC in the merge request itself.
:bulb: When PaC cannot start a pipelinerun on a mergerequest or pull request event for some reason like this, it should comment on the PR/MR with the reason. Even if not much useful information can be provided, it is better than radio silence.
There are some cases (like evaluation of on-cel-expression that precludes the execution of the pipelinerun) where a comment on the PR/MR is not desirable.