Deprecate unusable Step/StepTemplate fields

[lbernick]

Changes

Some fields of Step and StepTemplate only exist because they were inherited from
k8s Container, but they don't make sense in a batch workflow context and/or aren't
actually supported in Tekton. No changes to Sidecar.

This commit deprecates the following fields:

• Lifecycle, Ports, ReadinessProbe, LivenessProbe, StartupProbe, StdIn, StdInOnce, TTY:
  these don't really have a use in the context of Step
• TerminationMessagePath and TerminationMessagePolicy: these are extra confusing since Results are
  currently written as TerminationMessages
• StepTemplate.Name: Steps must have different names.

/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
• n/a 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

Deprecate unusable/unsupported fields of Step and StepTemplate

Closes #4737

[lbernick]

/assign @vdemeester @imjasonh

[imjasonh]

/lgtm

[imjasonh]

/lgtm

[lbernick]

/test pull-tekton-pipeline-integration-tests
/test pull-tekton-pipeline-alpha-integration-tests

[abayer]

/lgtm

[imjasonh]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: imjasonh

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:

• pkg/apis/OWNERS [imjasonh]

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

[vdemeester]

I am late to the party but 2 things:

• Can we rename the go fields prefixing them with Deprecated ? This won't have any impact on the API but could be used with something like https://github.com/knative/pkg/pull/2498/files#diff-c24a96cf293a6a5554a2148a1f8eec1e3c1e5dc27119181a565a5239698f6843L39
• Do we want to add an entry to the deprecation file to give a timeframe on when they will be removed ?

[lbernick]

• Can we rename the go fields prefixing them with Deprecated ? This won't have any impact on the API but could be used with something like https://github.com/knative/pkg/pull/2498/files#diff-c24a96cf293a6a5554a2148a1f8eec1e3c1e5dc27119181a565a5239698f6843L39

Not sure what you mean by this; are you suggesting renaming the struct types? They are owned by k8s. Or are you suggesting renaming the field names but keeping the json tags the same so that serialization/deserialization does not change?

• Do we want to add an entry to the deprecation file to give a timeframe on when they will be removed ?

I'm actually not sure what an appropriate timeline is here. Our compatibility policy says 9 months but it seems silly to wait 9 months to remove fields that aren't even currently usable.

[vdemeester]

Or are you suggesting renaming the field names but keeping the json tags the same so that serialization/deserialization does not change?

Yes, this is what I am suggesting 👼🏼

I'm actually not sure what an appropriate timeline is here. Our compatibility policy says 9 months but it seems silly to wait 9 months to remove fields that aren't even currently usable.

I tend to agree with that, but I don't really think we have a alternative. At least, we need to communicate what is the time schedule for those to be removed.

[lbernick]

Or are you suggesting renaming the field names but keeping the json tags the same so that serialization/deserialization does not change?

Yes, this is what I am suggesting 👼🏼

I'm actually not sure what an appropriate timeline is here. Our compatibility policy says 9 months but it seems silly to wait 9 months to remove fields that aren't even currently usable.

I tend to agree with that, but I don't really think we have a alternative. At least, we need to communicate what is the time schedule for those to be removed.

done in #4866