Watcher stores PipelineRun YAML without taskRunTemplate, podTemplate and env vars

[manuelwallrapp]

Expected Behavior

I expect that the PipelineRun YAML are saved completely as it appears in Openshift including the taskRunTemplate. But that is not the case.

kind: "PipelineRun" spec: ...... taskRunTemplate: podTemplate: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms:

• matchExpressions:
  • key: node-role.kubernetes.io/batch operator: Exists env:
    • name: CI value: 'true'

Actual Behavior

the complete taskRunTemplate under the PipelineRun spec is not stored, which makes an exact rerun of the stored YAML difficult. We need to store the taskRunTemplates with its env vars as well.

Steps to Reproduce the Problem

1. Start a PipelineRun with a defined taskRunTemplate which contains a podTemplate including env vars.
2. Compare the YAML in Openshift and the YAML in Tekton-Results. The whole taskRunTemplate with podTemplate is missing.

Additional Info

• Kubernetes version:

  Output of kubectl version:

  Client Version: 4.14.5
  Kustomize Version: v5.0.1
  Server Version: 4.14.14
  Kubernetes Version: v1.27.10+28ed2d7

• Tekton Pipeline version:

  Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

  Client version: 0.34.0
  Chains version: v0.16.1
  Pipeline version: v0.47.6
  Triggers version: v0.24.2

[khrm]

You will find these fields in a different location where they exist in v1beta1.

We need to move to v1 from v1beta1. There's already an issue on that and TEP.

[khrm]

@avinal I assume you will work on v1beta1 to v1 conversion soon? These issues will keep coming up if we don't move to v1 soon.

[manuelwallrapp]

I see, we can not do anything on our side, since our PipelineRuns are using v1 and TektonResults doesn't support yet the full structure of v1 including taskRunTemplate.

[khrm]

@manuelwallrapp Yes, when we move to v1 in Results, it will be resolved.

[thomascube]

I assume #303 is the related issue, right?

[khrm]

Yes. This should be fixed in v0.11.0