chmouel
commented
1 year ago I can understand the use case of letting centralised pipeline with all the definitions but things may gets funny when you have multiple definitions from the pipeline and pipelinerun with the same name... which one should we trust?
I'd rather be conservative with the remote annotations feature in general since this may be misused and cause hard to debug security breaches..
having said that we are working on evolving the way we fetch the pipelinerun definition to make it more flexible and pluggable, see https://issues.redhat.com/browse/SRVKP-3020
one resolver we would provide is a "default" one which would mean if there is no pipelinerun in .tekton/ fetch that default pipelinerun on push/pull... this may answer your use case..
When using a remote pipeline (as described in chapter "Using remote pipeline annotations with Pipelines as Code" in the documentation: https://docs.openshift.com/container-platform/4.11/cicd/pipelines/using-pipelines-as-code.html), it is not possible to reference remote tasks from the remote pipeline. In other words, when application repository has a .tekton with PipelineRun that uses a remote pipeline from another repository using annotation pipelinesascode.tekton.dev/pipeline - the tasks that the remote pipeline is using have to be available either on the execution cluster or be stored in application repository. What we want is that the remotely accessed pipeline would be able to use tasks from the same remote pipeline repository.
This scenario can be be also represented in this diagram: