feat: update chain's controllers to support both v1beta1 and v1 Tekton APIs via ConfigMap #1006

aaron-prindle · 2023-12-02T00:52:03Z

fixes #665 , fixes #985, fixes #986, fixes #987

This PR updates chains to natively use the Tekton Pipeline v1 API ("github.com/tektoncd/pipeline/pkg/apis/pipeline/v1"), updated from the Tekton Pipeline v1beta1 API ("github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1"). This PR additionally adds backwards compatibility support for v1beta1 Tekton Objects by adding an additional controller ([pipelinerun|taskrun].NewControllerV1Beta1) that can be toggled so that users can watch v1beta1 objects. The usage of either the v1 controller or the v1beta1 controller is toggled via a new bool chains ConfigMap option - tektonAPI.watchForTektonV1Beta1APIInstead. Internally in the provenance and signing logic v1 Tekton object representation is used w/ v1beta1 objects being converted in/out of v1 as needed for processing fields.

The backwards compatibility works as v1beta1 and v1 Tekton APIs can be converted between types. Due to v1beta1 changes over time, some fields have their own bespoke support (v1beta1 TaskRun .Spec.Resources, and .Status.TaskRunStatusField.TaskSpec.Resources). The implementation for the backwards compatibility w/ v1beta1 is designed around all of the chains methods supporting V1 TaskRun's + some bespoke logic for getting information from deprecated fields in V1. The flow for this is that when a V1Beta1 Tekton Objects is received by the controller, it convert it to a V1 object and adds some serialized information to the annotations (similar to https://github.com/tektoncd/pipeline/blob/main/pkg/apis/pipeline/v1beta1/taskrun_conversion.go, we would just rely on this but due to changes in v1beta1 over time the conversion methods no longer support what chains supported. See this PR here for an example - https://github.com/tektoncd/pipeline/pull/6150/files#diff-b9722861f4853020c0d7b0e17e92ffbf720b74b9c6e5550387ba3157dd210c94).

For a V1 object using the V1 controller, the flow is straightforward like it was initially with V1 objects being used throughout the signing process

For a V1Beta1 object using the v1beta1 controller, the flow has 4 main steps:

The received V1Beta1 Tekton Object ([PipelineRun|TaskRun]) is converted to a V1 Tekton Object adding some additional serialized fields to annotations that chains might need to use later when re-converting.
The V1 object is passed through all methods similar to the V1 controller
When certain extraction/signing logic is hit that needs to check .Spec.Resources, .Spec.ResourceResults, or .Status.TaskRunStatusField.TaskSpec.Resources we convert the V1 object back to V1Beta1 (using Tekton Pipeline conversion lib + bespoke deserialization code) and extract the necessary information as was done prior. Then the V1 Provenance is uploaded.
The originally received V1Beta1 object is passed to .Patch to be updated w/ chains annoations noting it was signed, etc.

The changes required were broadly the following:

s/v1beta1/v1 such that all internal signing/provenance logic uses V1
update objects.go TektonObject interface to be more generic to support to v1beta1 and v1 objects (some interface types were versioned @ HEAD - Result & Provenance). Making the controller more natively support v1beta1 and v1 is non-trivial as in many places the TektonObject is cast back to a versioned type (eg: v1, or @ priort-to-this-pr v1beta1) for reading fields directly, etc
add controllers (PipelineRun & TaskRun) for v1beta1 that converts to v1 internal representation and annotates v1beta1 object
where v1beta1 fields were used to generate provenance, add logic to convert back to v1beta1 to extract fields when necessary
convert any test files from v1beta1 -> v1
add ConfigMap option to watch v1beta1 OR v1. Supporting watching both (or making this the default) has the issue that w/ Tekton > 0.42.0 where it has the conversion webhook both a v1beta1 and v1 watch get triggered which makes watching both likely have strange edge cases as it can be processed twice

Open Questions:

I believe this will be able to fully support all of the currently supported Pipeline versions but OOC what is the current version range of support for Pipeline versions?
As v1 Tekton Objects are used internally, this means the provenance information uses the v1 Tekton object representation. Is this ok with regards to compatibility?
Are there any opinions/suggestions on the current method to have both v1beta1 and v1 Controllers in which both controllers exist and run w/ the ConfigMap option tektonAPI.watchForTektonV1Beta1APIInstead toggling the other controller into inactivity?

tekton-robot · 2023-12-02T00:52:06Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign wlynch after the PR has been reviewed.
You can assign the PR to them by writing /assign @wlynch in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

tekton-robot · 2023-12-02T00:58:11Z