Towards v1 API

[vdemeester]

This issue is here to track work towards the v1 API of tektoncd/pipeline. It is loosely based on the initial doc around this, and will be update as we go.

Motivation

In order to declare Pipeline stable and ready to use in production
to our users and customer, we need to give them some
guarantees. Although v1beta1 has some guarantees, most users are
waiting for a v1 API set that they can rely on for the long term.

If we can, in addition, come with a set of rules that would help us
decide when a feature request should be considered as required or not
for a v1 API, this would be nice 🙃.

Identified work

• API versions and new features Support Kubernetes style feature-gates for new API fields #3459 @vdemeester @skaegi @afrittoli
• Better credential UX Improve UX of getting credentials into Tasks #2343 @sbwsg
  • Consider projected volumes Consider better use of ProjectedVolumes #3551 (in relation to credential UX @sbwsg) — timebox work on investigation
• Additionnal workspace support (@sbwsg tracking issue to be created on workspaces)
• PipelineResource future Pipeline Resources Redesign #1673 @jerop @sbwsg @vdemeester
  • Tekton PipelineResources Beta Roadmap
• Resources Limit/Request & LimitRange support Improve UX of Step Resource Requests #2986 @vdemeester
• Failure strategies "when" expressions do not match user expectations #3345 [proposal] Capturing step exit codes in Tasks #2800 @jerop (if there is anything else to add)
• Custom tasks Implement Custom Tasks #3133 Integrate custom tasks into Pipelines #3463 @imjasonh @GregDritschler
• Migration path from v1beta1 to v1 @vdemeester
  • Documentation
  • Conversion webhook, …

Nice to have

• Redirect output streams Print all CRD as YAML on test failure #182 @chhsia0
• Pipeline concurrency limit provide a pipeline concurrency limit #1305
• Custom Scheduler Investigate to create a Custom Scheduler to schedule TaskRun pods #3052 - Timebox work on investigation
• Tekton OCI bundle enabled by default @vdemeester
• Proxy Support Proxy support for Pipeline *and* tasks #3090 facilitate mount of certs for HTTPS Proxy #2288 TEP-0033 Add tep for proxy support community#232 @piyush-garg
• PipelineRun and TaskRun Status PipelineRun and TaskRun Status #3792

To triage

• Provide a separate PipelineRun-volumeClaimTemplate, that can be mapped to multiple workspaces Allow volume from volumeClaimTemplate to be used in more than one workspace #3440 (in relation to workspaces @sbwsg)
• Task parallelism and Regional clusters - supported? Task parallelism and Regional clusters - supported? #3563

Use stories (to cover)

We should come with a bunch of user stories (from actual users) to highlight the requirements.

• A standard go project pipeline (lint, build, test)
• A standard Java project pipeline (lint, package, test, publis, …) — maven and gradle versions
• A source-to-image project pipeline (build image, test, deployment)
• A source-to-image in knative project pipeline (build image, deployment, test, deployment)
• Tekton pipeline project pipeline (lint, build, test, e2e test against a cluster, …)
• A canary deployment pipeline
• A “matrix” build pipeline (build, test, … with some different env’ variables — using CustomResource)
• A Kubernetes pipeline execution engine for Kubeflow pipeline to leverage ML pipeline use cases (Python DSL to Tekton pipelineRuns, Data Transformation/processing, test, deploy and monitor k8s model training CR, model examination)
• Add yours here

See also here 😅

/area epic
/area roadmap
/kind feature
/assign

/cc @tektoncd/core-maintainers

[jlpettersson]

I would like to see #3440 in v1 - and deprecate the current place were volumeClaimTemplate is implemented. That would be a more intuitive API - easier to understand and easier to work with. I really regret the current design.

I also think #3551 would be nice to do / try out before v1.

Replace the Affinity Assistant with a Custom Scheduler #3052 would also be nice - even though not strictly an API-thing, but before 1.0. Personally I would prefer the current constraints since I, as default expect 1) that declared parallel tasks can execute in parallel - with PVC, 2) that pipelineruns can not deadlock depending on how I use PVCs

[bobcatfish]

I think that making some changes to the constraints the affinity assistant imposes before v1 would make a lot of sense - for example I really don't like it that (unless im understanding incorrectly) trying to use 2 PVCs with 1 Task right now will not be allowed (unless you disable the affinity assistant). Even if we keep that, I think it shouldn't be the default.

[jlpettersson]

@bobcatfish I opened #3563 for discussion

[bobcatfish]

@vdemeester maybe we can triage #3163 and potentially have it as part of our v1 roadmap?

[vdemeester]

@vdemeester maybe we can triage #3163 and potentially have it as part of our v1 roadmap?

Except in " Migration path from v1beta1 to v1 " I don't see how it affects the v1 API 🤔.

[bobcatfish]

I think it's part of the migration path @vdemeester - when we add v1, we'll have another API type to worry about having end to end tests for

[bobcatfish]

@vdemeester possible item to triage: have we discussed at all revisiting the structure of the status sections of TaskRun and PipelineRun? I don't think these were designed as carefully as the spec sections and there is some odd stuff in there. Or we can say it's good enough and go to v1 - but I think if we wanted to change it at all, we'd want to try to do it pre-v1

[vdemeester]

@vdemeester possible item to triage: have we discussed at all revisiting the structure of the status sections of TaskRun and PipelineRun? I don't think these were designed as carefully as the spec sections and there is some odd stuff in there. Or we can say it's good enough and go to v1 - but I think if we wanted to change it at all, we'd want to try to do it pre-v1

We can definitely discuss that :)