-
Bug
-
Resolution: Done
-
Major
-
Pipelines 1.13.0
-
1
-
False
-
None
-
False
-
SECFLOWOTL-117 - Enhancing Task/Pipeline Resolving Support in PAC
-
Pac will not resolve any pipeline in .tekton dir which is not part of the pipelineruns filtered for the event
-
-
-
1
-
Pipelines Sprint 256, Pipelines Sprint 257, Pipelines Sprint 258, Pipelines Sprint 259, Pipelines Sprint TekShift 6, Pipelines Sprint TekShift 7, Pipelines Sprint TekShift 9, Pipelines Sprint TekShift 10, Pipelines Sprint TekShift 11, Pipelines Sprint TekShift 12, Pipelines Sprint Pioneers 13
Description of problem:
Client is facing issue which is stopping them from having multiple PipelineRun objects for the same repo, which limits their ability to customize their pipelines installation and is stopping from rolling out a pipeline.
Workaround:
As a workaround client needs to add every remote task import to every pipelinerun for every task required by every pipelinerun.
Prerequisites (if any, like setup, operators/versions):
Openshift Pipelines operator: 1.13
OCP: 4.12.34
Steps to Reproduce:
Minimal reproducer steps are been shared by the client. Attached to the drive link.
Actual results:
When client create a github PR from the branch `new-pipeline`, the pipelinerun `pipelinerun-a` should run with no issues with the result being that `task-a` runs to completion in a TaskRun that is associated with `pipelinerun-a` `pipelinerun-b` should not run.
Instead of the pipelinerun object being created on the cluster, the controller returns the following error message in the github pull request:
```
There was an issue validating the commit: "cannot find referenced task task-b. if it's a remote task make sure to add it in the annotations"
```
What is happening is that during pipeline as code resolution when `pipelinerun-a` is being resolved into a embedded pipelinerun, the pipelines as code controller also tries to resolve all dependencies for `pipelinerun-b`, but it doesn't have the annotations for pipelinerun-b. The solution is to add every remote task import to every pipelinerun for every task required by every pipelinerun. This quickly gets tedious, and makes it harder to keep track of which dependencies are needed for each pipelinerun.
Expected results:
When client create a github PR from the branch `new-pipeline`, the pipelinerun `pipelinerun-a` should run with no issues with the result being that `task-a` runs to completion in a TaskRun that is associated with `pipelinerun-a`.
`pipelinerun-b` should not run.