tektoncd
Add support for `v1` Types
Feature request
tektoncd/pipeline now ships with a v1 API. Catlin should support validating them.
Use case
Support the newest api version (and the stable / ga version)
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.
thank you @vdemeester for raising this issue.
did some exploration on the code base and related v1 docs..
- mainly the script.go, parse.go, and task_validator.go are coded with the v1beta1 objects, like *.Task or *.Step.
- tried to flip the version as v1, the current unit tests pass still because there is no diff for validated parts of the fields between the 2 versions, like script or img. (I referred here https://github.com/tektoncd/pipeline/blob/main/docs/migrating-v1beta1-to-v1.md)
- one exception is parser.go - there are *.Task and *.ClusterTask. as I checked the current pipeline configs, the *.ClusterTask is only on v1beta1.
thinking likely we need to support validations for both versions, I should not just flip the version in the code. perhaps we need to implement and structure the code, somehow like the pipeline https://github.com/tektoncd/pipeline/tree/main/pkg/apis/pipeline - so diff folders for the v1 and v1beta1 versions... also, we might need to implement new rules for the updated v1 api.
some initial thoughts, how about your ideas?
hi @vdemeester, wave my hands here ;)
any more contexts perhaps we could have here. we are trying to update the v1beta1 reference to v1, but met the question likely we will still need to support the v1beta1. also we are not quite sure what will be validation rules updated here between the 2 versions.
loop @arifash01 in