Upgrade Tekton Model to v0.47.0

[dziemba]

Description

• Upgrade Tekton Pipelines to v0.47.0
• Upgrade Tekton Triggers to v0.24.0
• Add the new v1 Tekton Pipelines API Group
• Merge generator code into single package per module (to avoid duplicating boilerplate + version drifts between API groups) and remove obsolete Golang setup (e.g. vendoring)
• Rename ArrayOrString to ParamValue (has been renamed upstream)
• Fix various tests, delete obsolete ones

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[rohanKanojia]

@dziemba : I think we should keep old generators v1alpha1 and v1beta1 for backward compatibility.

[dziemba]

First off: This whole PR turned out a bit larger than I anticipated. If you like me to split up some things or revert some of the (opinionated) changes, I'm happy to do that :)

I think we should keep old generators v1alpha1 and v1beta1 for backward compatibility.

Do you mean keeping them pinned to the older Tekton versions? I thought about that, and backwards compatibility would be super nice to have. The problem I see with that approach though is how Tekton creates new APIs. They start in alpha, then get promoted to beta and then to stable apparently.

Looking at the changes for v1alpha1, we are losing most of the old objects, which breaks backwards compatibility. But we also get two new objects, which we wouldn't be able to use if we're pinning v1alpha1 to an older Tekton version.

I think ideally we would need to have multiple packages for different Tekton versions, that each contain all API group models for that given version. That will quickly become a lot of code and maintenance effort though. Especially since Tekton is still on v0.x.

How do you suggest we proceed here? I'm happy to revert the changes to v1alpha1 back to how it was, but I'm a bit worried that won't be very future-proof.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

1.1% Coverage
38.2% Duplication

[rohanKanojia]

@shawkins @manusa : Could you please provide some guidance on what should be the appropriate strategy here? Shall we keep old apiGroups to older versions or switch to the latest versions.

[dziemba]

@rohanKanojia @shawkins @manusa Any update on which direction to go in? I'm happy to change this PR as you see fit :)

[dziemba]

@vdemeester @afrittoli @bobcatfish (Tekton topical owners for API Versioning) do you have any suggestions on what the right approach here is?

[vdemeester]

I am not sure I fully followed but tekton follow the same practices as k8s. API versions go from alpha to stable. Some alpha types can be removed as, as state in most api practice, alpha is.. breakable, from one release to the other, breaking changes on field or removal of a type can happen.

I think a library should focus more on the api it supports than tekton version themselves. A gist from the doc

• a v1 type today should work the same in one year (~10/12 releases) as everyting has to be done in a backward compatible way
• a v1beta1 type today should work the same in 9 month — after that "some" fields could be removed if properly marked as deprecated
• a v1alpha1 type can break tomorrow

As of today (0.46), most types are either in v1 (the main ones, like Pipeline, Task, …) and v1beta1 (CustomRun, …). So support Pipeline, Task, … v1alpha1 makes very little sense (because it would basically only work on relatively old version of tektoncd/pipeline, that are not really supported anymore).

[rohanKanojia]

@dziemba : I think we can move forward with this change

[dziemba]

Thanks for the review, I'll address the feedback soon

[dziemba]

@rohanKanojia I addressed all feedback now, please have another look :)

[manusa]

Hi @dziemba,

Sorry for the late feedback. This morning we noticed that some of the structs are missing.

More specifically, the Interceptor in the triggers module (https://pkg.go.dev/github.com/tektoncd/triggers@v0.23.1/pkg/apis/triggers/v1alpha1#Interceptor).

Could you please add that one too?

[dziemba]

@manusa Sure, I've now added the Interceptor types.

Update: I forgot to add the new type to the API DSL, I just pushed a new commit that includes these changes as well.

[manusa]

@manusa Sure, I've now added the Interceptor types.

Update: I forgot to add the new type to the API DSL, I just pushed a new commit that includes these changes as well.

Hi @dziemba, sorry for the late updates. We've been trying to release a stable 6.6 version.

If you covered everything we mentioned, then it should be good to go. Don't worry about changelog conflicts or similar. If you checked the Allow edits and access to secrets by maintainers I should be able to take care of that.

[rohanKanojia]

This is also affected by #5113 . We should refactor trigger generators to remove the split package warning.

[metacosm]

Should we update triggers to 0.24 that got released last week?

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
9 Code Smells

1.1% Coverage
34.2% Duplication

[manusa]

CHANGELOG was not correctly updated, I'll fix after merging to avoid re-running all pipelines.

Improvement entries need to be removed

[manusa]

LGTM, thx @dziemba!