Remove v1alpha1 Pipeline, PipelineRun, Task, TaskRun, and ClusterTask

[abayer]

Changes

Closes #4982

This removes the long deprecated pipeline v1alpha1 APIs for everything that's replicated in v1beta1.

/kind cleanup

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Docs included if any changes are user facing
• Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Release notes block below has been filled in
  (if there are no user facing changes, use release note "NONE")

Release Notes

action required: `v1alpha1` `Pipeline`, `PipelineRun`, `Task`, `TaskRun` removed. Please switch to `v1beta1` for those types.

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/resources/pipelineref.go	87.5%	85.7%	-1.8
pkg/reconciler/taskrun/resources/taskref.go	78.6%	74.5%	-4.1

[abayer]

/retest

[abayer]

/retest

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/resources/pipelineref.go	87.5%	85.7%	-1.8
pkg/reconciler/taskrun/resources/taskref.go	78.6%	74.5%	-4.1

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/resources/pipelineref.go	87.5%	85.7%	-1.8
pkg/reconciler/taskrun/resources/taskref.go	78.6%	83.0%	4.4

[abayer]

I...honestly did not expect everything to pass so soon. =)

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/resources/pipelineref.go	87.5%	85.7%	-1.8
pkg/reconciler/taskrun/resources/taskref.go	78.6%	83.0%	4.4

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/resources/pipelineref.go	87.5%	85.7%	-1.8
pkg/reconciler/taskrun/resources/taskref.go	78.6%	83.0%	4.4

[vdemeester]

/cc @tektoncd/cli-maintainers as this will have an impact on the CLI (a good one, we'll have to clean our v1alpha1 support as well)

[abayer]

And yes, there'll be an email to tekton-dev@ once this merges.

[abayer]

/retest

[abayer]

cc @tektoncd/core-maintainers

[abayer]

/hold

I'm holding this until I get feedback from enough people. =)

[vdemeester]

I tend to agree with @afrittoli. Custom Tasks are only available if we set the api feature flag to alpha, so we consider those features alpha (with an alpha timeline). This means if next release we want to remove it (or here rename it), we could (it would be better to do it in a "as little breakage as possible" way but still…).

Custom Tasks are even more "weird" in that, from the user perspective (aka the yaml provide) we never "refer" to the Run type. It almost make Run an implementation detail that is not visible to the end-user. It is however visible for tools integrating with pipeline.

I feel like we discussed about this already, but I cannot remember for sure.
I'm not sure I see enough value in changing the name to justify it, but also I'm not opposed to it.
@imjasonh @vdemeester wdyt?

I don't have a strong opinion on this, but if we want to change the name, it would be better to do it earlier than later. Changing it today, would mean all the custom task in experimental need to be changed, same with external ones (automatiko manual approval, …).

We could introduce a v1alpha2 which would only be a thin shim i.e. identical to v1beta1 with alpha feature enabled. That v1alpha2 API would allow getting access to alpha features without changing the config. Do you think that would be useful?

That could be a possibility. I wonder what are the cons for this approach, what problems it could "pose".

[lbernick]

@wlynch

I'm curious because one of the things I was hoping could happen eventually was renaming Run -> CustomRun while the feature is still alpha

Let's keep "Run" naming out of scope for this PR.

Mixing different stability policies in the same API makes it a bit confusing what is / isn't in scope

I agree this can be confusing although this is covered in tep 33

• e.g. if we make a breaking change to how CustomRuns are referred to in v1beta1 APIs, does that need to follow beta compatibility deprecation?

Yes, but I don't think that's in scope for this PR.

While I'm all for simplifying the maintenance burden of v1alpha1, part of me wonders if there's value in keeping a thin layer so we can quickly iterate on experimental features without needing to impact higher stability APIs. 🤔

I'm not sure I understand what you're suggesting here. Is the suggestion to retain the concept of a "v1alpha1 API" which has v1alpha1 versions of all the CRDs you would need to run Tekton? v1alpha1 Run will still exist, at alpha stability, so we can iterate on it. Or is the concern that the v1beta1 Pipeline implicitly declares the spec of Run (currently runtime.RawExtension), so there's a beta CRD that depends on Run spec? If the latter, I think this is also out of scope.

[wlynch]

I'm not sure I understand what you're suggesting here. Is the suggestion to retain the concept of a "v1alpha1 API" which has v1alpha1 versions of all the CRDs you would need to run Tekton?

Yup! (though probably more in line with what @afrittoli was saying with v1alpha2).

Or is the concern that the v1beta1 Pipeline implicitly declares the spec of Run (currently runtime.RawExtension), so there's a beta CRD that depends on Run spec? If the latter, I think this is also out of scope.

The situation I'm worried about is if a change to an alpha field causes a breaking change in beta API clients - it's not immediately obvious in client code whether a beta client is running in "alpha mode", since that's a server-side setting. We kinda get around this today by having alpha checks during validation, though I don't think we have any way to verify what fields are alpha beyond doc comments (and we're not always consistent about labelling these) and whether they are actually enforced as alpha. For me having strict separation of alpha fields only be in alpha APIs makes this distinction clearer for both client and server, then promote fields to beta once we're happy. If we do stick with the alpha fields in beta APIs though, maybe we can do something to improve this like add custom struct tags to label and enforce alpha behavior. 🤔

That said, agreed that this is out of scope for this PR so...

/lgtm

[abayer]

@wlynch fwiw, v1alpha1 didn't have alpha features, it was just the first version of the API. All the alpha features are in v1beta1.

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli, vdemeester

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [afrittoli,vdemeester]

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

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/resources/pipelineref.go	87.5%	85.7%	-1.8
pkg/reconciler/taskrun/resources/taskref.go	78.6%	83.0%	4.4

[lbernick]

/lgtm

[abayer]

/retest

[abayer]

/hold cancel

[abayer]

/retest

[abayer]

/test pull-tekton-pipeline-integration-tests

[abayer]

/retest

[abayer]

/test pull-tekton-pipeline-integration-tests

[tekton-robot]

@abayer: The specified target(s) for /test were not found.
The following commands are available to trigger required jobs:

• /test stage-tekton-pipeline-unit-tests

In response to this:

/test pull-tekton-pipeline-integration-tests

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[abayer]

/test pull-tekton-pipeline-integration-tests