Add Task to v1alpha2 🎋

[vdemeester]

Changes

This modify how TaskSpec looks from v1alpha1:

• params is now directly under spec
• no more inputs and outputs, get replaced by resources
• resource has input and output resource declaration fields, similar
  to how it is used in Pipeline

The spec will look like this (only thing that changed from v1alpha1).

spec:
  params:
     # params here
  resources:
    inputs:
      # inputs resources here
    outputs:
      # outputs resource here

The next step are :

• Add more types (Pipeline, TaskRun, PipelineRun, Condition)
• Refactor v1alpha1 to embedded v1alpha2 (for storage purpose)
• Auto-conversion from v1alpha1
• Document v1alpha2 (will do "when" we expose it 👼)

This is "a start", the next step can be done in a follow-up (as well as enhancing the tests 😉).
I did not remove tests from types that are shared between the two version as I want to make sure v1alpha1 behaves the same still.

We need to follow closely what changes are done on v1alpha1 package from now on, to make sure we "report" them to v1alpha2 at some point 👼

/cc @bobcatfish @skaegi @afrittoli

Signed-off-by: Vincent Demeester [email protected]

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide for more details.

Double check this list of stuff that's easy to miss:

• If you are adding a new binary/image to the cmd dir, please update
  the release Task to build and release this image.

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

[tekton-robot]

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

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/merge.go	72.4%	100.0%	27.6
pkg/apis/pipeline/v1alpha1/resource_types.go	75.0%	75.8%	0.8
pkg/apis/pipeline/v1alpha2/merge.go	Do not exist	72.4%
pkg/apis/pipeline/v1alpha2/param_types.go	Do not exist	94.7%
pkg/apis/pipeline/v1alpha2/register.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/resource_types.go	Do not exist	89.3%
pkg/apis/pipeline/v1alpha2/resource_types_validation.go	Do not exist	100.0%
pkg/apis/pipeline/v1alpha2/substitution.go	Do not exist	17.8%
pkg/apis/pipeline/v1alpha2/task_defaults.go	Do not exist	66.7%
pkg/apis/pipeline/v1alpha2/task_types.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/task_validation.go	Do not exist	74.8%

[tekton-robot]

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

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/merge.go	72.4%	100.0%	27.6
pkg/apis/pipeline/v1alpha1/resource_types.go	75.0%	75.8%	0.8
pkg/apis/pipeline/v1alpha2/merge.go	Do not exist	72.4%
pkg/apis/pipeline/v1alpha2/param_types.go	Do not exist	94.7%
pkg/apis/pipeline/v1alpha2/register.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/resource_types.go	Do not exist	89.3%
pkg/apis/pipeline/v1alpha2/resource_types_validation.go	Do not exist	100.0%
pkg/apis/pipeline/v1alpha2/substitution.go	Do not exist	17.8%
pkg/apis/pipeline/v1alpha2/task_defaults.go	Do not exist	66.7%
pkg/apis/pipeline/v1alpha2/task_types.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/task_validation.go	Do not exist	74.8%

[tekton-robot]

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

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/resource_types.go	75.0%	75.8%	0.8
pkg/apis/pipeline/v1alpha2/merge.go	Do not exist	72.4%
pkg/apis/pipeline/v1alpha2/param_types.go	Do not exist	94.7%
pkg/apis/pipeline/v1alpha2/register.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/resource_types.go	Do not exist	89.3%
pkg/apis/pipeline/v1alpha2/resource_types_validation.go	Do not exist	100.0%
pkg/apis/pipeline/v1alpha2/substitution.go	Do not exist	17.8%
pkg/apis/pipeline/v1alpha2/task_defaults.go	Do not exist	66.7%
pkg/apis/pipeline/v1alpha2/task_types.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/task_validation.go	Do not exist	74.8%

[ghost]

We talked about this on the beta call yesterday but just to recap :-

I suggest that alpha2 methods should depend on the alpha1 method in any case where the alpha2 method is exactly the same as alpha1. Then if a dev wants to modify the way alpha2 works in the future they would copy/paste alpha1's method implementation into alpha2 and make changes to that copy.

This is all in service of keeping alpha1 frozen after alpha2 is released - after alpha2 is released we should instantly be able to tell if there's a problem with a PR simply by noticing that an alpha1 file has been modified. WDYT?

[vdemeester]

We talked about this on the beta call yesterday but just to recap :-

I suggest that alpha2 methods should depend on the alpha1 method in any case where the alpha2 method is exactly the same as alpha1. Then if a dev wants to modify the way alpha2 works in the future they would copy/paste alpha1's method implementation into alpha2 and make changes to that copy.

So I remember now why I did the opposite. In my experimentation of bumping the API, I am using v1alpha1 as stored structure. One of the main reason is that it allows to keep the next api uncluttered with previous API. In this model (same as knative), APIs know its direct chield but not its parent (aka v1alpha1 knows v1alpha2, v1alpha2 knows v1alpha3 and v1alpha3 knows nobody if it's the latest API). This means, v1alpha2 can't depend on v1alpha1 as this creates a cyclic dependency — and go doesn't handle that.

This is all in service of keeping alpha1 frozen after alpha2 is released - after alpha2 is released we should instantly be able to tell if there's a problem with a PR simply by noticing that an alpha1 file has been modified. WDYT?

Ideally, except for exact similar types (and for similar types, type aliasing help greatly), we should try to get as less code on v1alpha1 depending on v1alpha2 (this is mainly for functions). Anything that can be extracted out of the api package is even better (because it cuts the cycle dependency). This also means we may need a bit more duplicate code in some places — but for relative short time (at least for alpha APIs).

So for the merge.go file for example, duplication might be the way to go (with a small refactor to, maybe, extract what can be extracted in a common package).

[vdemeester]

/test pull-tekton-pipeline-integration-tests

[tekton-robot]

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

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1alpha1/resource_types.go	75.0%	75.8%	0.8
pkg/apis/pipeline/v1alpha2/merge.go	Do not exist	72.4%
pkg/apis/pipeline/v1alpha2/param_types.go	Do not exist	94.7%
pkg/apis/pipeline/v1alpha2/register.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/resource_types.go	Do not exist	89.3%
pkg/apis/pipeline/v1alpha2/resource_types_validation.go	Do not exist	100.0%
pkg/apis/pipeline/v1alpha2/substitution.go	Do not exist	17.8%
pkg/apis/pipeline/v1alpha2/task_defaults.go	Do not exist	66.7%
pkg/apis/pipeline/v1alpha2/task_types.go	Do not exist	0.0%
pkg/apis/pipeline/v1alpha2/task_validation.go	Do not exist	74.8%

[dibyom]

/lgtm

[ghost]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbwsg

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 [sbwsg]

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

[vdemeester]

/test pull-tekton-pipeline-integration-tests