Rename containerTemplate to stepTemplate 👠

[bobcatfish]

Changes

We used the term containerTemplate for this template b/c it is a
template of the containers used for each step - however we don't refer
to those as containers, we refer to them as steps, so I think calling
this stepTemplate makes slightly more sense and makes the relationship
between this template + the steps a bit more obvious.

This change is backward compatible b/c both containerTemplate and
stepTemplate will be supported until #977 where we will make the
backward incompatible change and remove containerTemplate.

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.

Release Notes

🚨 Please migrate from `containerTemplate` to `stepTemplate` 🚨
The field `containerTemplate` in `Task` is now called `stepTemplate`. `containerTemplate` will be removed in the next release (#977)

[bobcatfish]

@abayer I think this is relevant to your interests! 🙏

[bobcatfish]

And this is an API change so would like to review from several of @vdemeester @dlorenc @imjasonh ❤️

[vdemeester]

/hold
(so that we have time to review 👼)

[vdemeester]

I am 👍 on this change as it's more coherent with the steps field.
We will need a huge warning in the release note. I don't think there is any task in the catalog using containerTemplate yet, but we will need to make sure and follow-up in there. Also, the fact that this is green, it feels we don't have yaml tests using containerTemplate here, would be cool to have some 👼

[abayer]

/lgtm

I’m a strong +1 on this. It’s definitely a more explanatory name!

[bobcatfish]

We will need a huge warning in the release note.

maybe we can have a section in the future for "backwards incompatible changes". Leave this one with me! :D

Also, the fact that this is green, it feels we don't have yaml tests using containerTemplate here, would be cool to have some angel

Added!

[bobcatfish]

PTAL :D

/meow space

[tekton-robot]

@bobcatfish:

In response to this:

PTAL :D

/meow space

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]

/lgtm
/meow box

[tekton-robot]

@abayer: Bad category. Please see https://api.thecatapi.com/api/categories/list

In response to this:

/lgtm
/meow box

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]

/meow boxes

Dang it. =)

[tekton-robot]

@abayer: Bad category. Please see https://api.thecatapi.com/api/categories/list

In response to this:

/meow boxes

Dang it. =)

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]

/meow boxes

[tekton-robot]

@abayer:

In response to this:

/meow boxes

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.

[bobcatfish]

it was all worth it 🐱

[vdemeester]

/lgtm

[vdemeester]

cc @dlorenc @imjasonh for last reviews 👼

[bobcatfish]

@imjasonh suggested that we use this change to try out rolling out a backward incompatible change across 2 releases so I'm gonna do that!

[afrittoli]

The most direct consumers of the pipeline API are the other Tekton projects, so we could try and make sure we coordinate the release with them.
How's the roll out across 2 releases going to work?

[bobcatfish]

How's the roll out across 2 releases going to work?

1. A release would go out that supports both the old way and the new way, with a warning
2. The next release would actually drop the old way and be backward incompatible

There's more about this at https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#possibly-beta-in-03 (where we theorize we might go beta in 0.3 haha... maybe we should go beta now though, it seems like folks are surprised by the idea that we might make a backward incompatible change? 🤔 )

[vdemeester]

How's the roll out across 2 releases going to work?

1. A release would go out that supports both the old way and the new way, with a warning
2. The next release would actually drop the old way and be backward incompatible

There's more about this at https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#possibly-beta-in-03 (where we theorize we might go beta in 0.3 haha... maybe we should go beta now though, it seems like folks are surprised by the idea that we might make a backward incompatible change? thinking )

So, overall we could have something like that. We should try to follow Kubernetes deprecation policy as much as possible.

Rule #1: API elements may only be removed by incrementing the version of the API group.
Rule #2: API objects must be able to round-trip between API versions in a given release without information loss, with the exception of whole REST resources that do not exist in some versions.
Rule #3: An API version in a given track may not be deprecated until a new API version at least as stable is released.
Rule #4a: Other than the most recent API versions in each track, older API versions must be supported after their announced deprecation for a duration of no less than:
GA: 12 months or 3 releases (whichever is longer)
Beta: 9 months or 3 releases (whichever is longer)
Alpha: 0 releases
Rule #4b: The “preferred” API version and the “storage version” for a given group may not advance until after a release has been made that supports both the new version and the previous version

As we are in Alpha right now, we don't really have anything to do, this is the reason why we use v1alpha1 on Tekton API right now, is so that people building on it know that we might make a backward incompatible change. That's why I think only a release note can be sufficient for that, and for now.

We could also, bump the version to v1alpha2, which could help us do 2 things:

• for people building on top of tekton to migrate at their pace on a new API
• for us to manage multiple api version as it's gonna be required in the near future anyway 👼

And, this brings to the table a discussion about how and when to promote our API to the Beta phase, aka v1beta1, v1beta2, …

[bobcatfish]

Created #977 to actually make the backward incompatible change.

[bobcatfish]

Okay I've updated the change in this PR to be backward compatible for now - PTAL @vdemeester @abayer @chmouel @imjasonh @afrittoli 😸

[vdemeester]

@bobcatfish needs a rebase 😓 otherwise looking good (took the same approach for #1004 )

[bobcatfish]

This should be rebased and ready to go now @vdemeester !

/hold cancel

[vdemeester]

/lgtm
A quick update is gonna be needed in the tektoncd/catalog once we do a release

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bobcatfish, chmouel, 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 [bobcatfish,vdemeester]

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