Ensure Chains works with the v1 version of TaskRuns and PipelineRuns

[jagathprakash]

Pipelines APIs have been updated to v1 from v1beta1.
Make sure that these versions work well with Chains.

Starting on the work here, made some issues to track the subtasks: Thanks @aaron-prindle !!

• [chains-v1.0.0] Convert Tekton v1 Object References Back to v1beta1 for backwards compatibility for Provenance Formatting #985
• [chains-v1.0.0] Convert incoming v1beta1 object to v1 before converting #986
• [chains-v1.0.0] [obsolete] Add a configMap option for the version that the Chains controller should watch (v1 or v1beta1). #987

[bendory]

Context: today chains is only watching v1beta1 pipelines:

• taskrun.Reconciler
• pipelinerun.Reconciler

[lcarva]

I wonder if it's possible for Chains to handle both v1beta1 and v1. That would facilitate adoption.

[bendory]

I wonder if it's possible for Chains to handle both v1beta1 and v1. That would facilitate adoption.

+1

In fact, we need a spin-off issue around handling cross-version compatibility with pipelines changes.

[vdemeester]

So, technically, as long as v1beta1 is served by tektoncd/pipeline, chains will work because the controller watches v1beta1 types, which are automatically converted, no matter how the user created them. This means that, today, if a user creates a v1 type, chains will handle it (because it will get it while watching v1beta1 objects).

I think, in a few release (most likely, more or less at the same time 0.47 gets release with a storage version change), chains should switch from watching v1beta1 to v1. This would make chains not working with older pipeline version (older than 0.43), but I think at some point this will be fine.

We may want to rename this issue to "switch chains controller to watch v1 types" instead 👼🏼

[bendory]

Immediate AIs:

• future releases of chains need to include release notes on compatibility with pipeline versions
• future releases of pipelines need to include release notes on compatibility with chains versions

TEP please:

• enhance chains and pipelines such that installation of a version incompatible with the existing installation would fail or at least alert to the problem

[vdemeester]

@bendory definitely +:100: on your checklist ❤️

[vdemeester]

/area roadmap

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/lifecycle frozen

[chitrangpatel]

Here is the proposed action plan for this:

1. Switch to using v1 internally in Chains (throughout)
2. Convert all v1beta1 objects to v1 in the controller/object interface.
3. Wherever there are deprecated things like pipelineResources , we could partially convert back to v1beta1 where needed so that appropriate things can be assessed.

This would completely satisfy chains/v1 predicate.

The only issue is with v2alpha2 where we embed the complete runSpec. We could leverage the configMap for that and depending on the desired version, convert to v1 or v1beta1 before sticking it into the provenance.

Eventually, when v1beta1 is deprecated, we could remove support for the deprecated fields from Chains.

[chitrangpatel]

/assign

[aaron-prindle]

Starting on the work here, made some issues to track the subtasks:

• [chains-v1.0.0] Convert Tekton v1 Object References Back to v1beta1 for backwards compatibility for Provenance Formatting #985
• [chains-v1.0.0] Convert incoming v1beta1 object to v1 before converting #986
• [chains-v1.0.0] [obsolete] Add a configMap option for the version that the Chains controller should watch (v1 or v1beta1). #987

If someone has comment edit access, feel free to make this an [Umbrella Tracking] issue and put this checklist in the top comment

[chitrangpatel]

/assign @aaron-prindle

[aaron-prindle]

Dropping in some notes/info from todays Tekton Chains WG meeting:

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?
  • Last Pipeline LTS version is the long tail
    • v0.44.0 is the oldest LTS
    • ^ some flexibility, possibly ok to remove old int tests
• 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?
  • ^ Likely important to have v1beta and v1 payload format
  • ^ how does user select this option (v1beta vs v1 Provenance)?
    • Configmap option // feature flag
    • In format for the config, we can choose SLSA v1, v0.2, v2alpha2
    • Maybe can have new format, v2alpha3, ???
    • artifacts.taskrun.format
    • artifacts.piplelinerun.format
      • Chains versions of outputting SLSA data
      • slsa/v2alpha2
      • slsa/v2alpha3?
• 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?
• taskrun_conversion.go from tektoncd/pipeline for v1beta1 removed some deprecated fields chains uses. Currently the PR manually fixes this to support chains operation, wanted to understand if this was appropriate
  • https://github.com/tektoncd/pipeline/pull/6150/files#diff-fbf27a13d37edb024cd1018c460dfdbc44f4ddbbdbb9ef676c0e73b08cdeeeb1L363

AIs

• Remove v1beta1 support and old Pipeline versions E2E tests (v0.41.3 no longer supported, ok to drop 🙌)
• Add support for v1beta1 payload to make sure users don’t have stored provenance change on them
• Instead make v1 storage type mapped to slsa/v2alpha3 (or slsa/v*) for better UX