Sort pod container statuses based on Step order in taskSpec

[Peaorl]

Changes

This commit closes #3239

Tekton determines the TaskRun status message of a failed TaskRun based on the results of the first terminated Step (pod container). Until now, Tekton sorted pod container statuses based on the FinishedAt and StartedAt timestamps set by Kubernetes.
Occasionally, a Step terminated in response to the first terminated Step could have the same timestamps as the first terminated Step.
Therefore, Tekton was not always able to correctly determine what the first terminated Step was, and as a result, Tekton may set an incorrect TaskRun status message.

In this commit, pod container statuses are sorted based on the container order as specified by Tekton in the podSpec.
Tekton bases this order on the user provided taskSpec and Steps added internally by Tekton. Therefore, Tekton accounts for internally added Steps when sorting pod container statuses.

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)
• Commit messages follow commit message best practices
• Release notes block has been filled in or deleted (only if no user facing changes)

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.

Release Notes

Steps in the TaskRun status field are now sorted according to the Step order specified in the taskSpec

[tekton-robot]

Hi @Peaorl. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[vdemeester]

/kind bug
/ok-to-test
@Peaorl this might need a release note (other than NONE) 😛

[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/pod/status.go	87.0%	93.4%	6.4
pkg/termination/parse.go	100.0%	84.2%	-15.8

[GregDritschler]

In this commit, pod container statuses are sorted based on the Step order set in the taskSpec. This order ought to be correct as Tektonenforces Steps to be scheduled in this order. In case Tekton adds extra Steps (such as for pipelineresources), Tekton already updates the taskSpec with these Steps. Therefore, Tekton accounts for these internally added Steps when sorting.

The taskSpec passed to MakeTaskRunStatus does not have the internal steps. It is the user's taskSpec.

Perhaps you are looking at the steps in the TaskRun's status? Those do have the internal steps because the code fabricates steps for them from the container statuses. You'll notice those steps are not in order relative to the user's steps.

I suggest testing a TaskRun with a PipelineResource that has an error (e.g. a git resource with a repo that doesn't exist), to confirm the behavior.

Also this change needs to be separated from your other PR #3138 (or, if it depends on it, you need to hold this one until that one is approved and merged).

[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/pod/status.go	87.0%	93.4%	6.4
pkg/termination/parse.go	100.0%	84.2%	-15.8

[Peaorl]

Thanks @GregDritschler ! Good catch, I made sure the updated taskSpec is passed on to the appropriate function (MakeTaskRunStatus).

/hold

[GregDritschler]

Thanks @GregDritschler ! Good catch, I made sure the updated taskSpec is passed on to the appropriate function (MakeTaskRunStatus).

So now the updated taskSpec is passed to MakeTaskRunStatus when the pod is created, but what happens on subsequent reconcile calls when the pod exists?

[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/pod/status.go	93.3%	93.3%	-0.0

[Peaorl]

I changed it such that the container order in the podSpec is used. Tekton sets this container order when the pod is created and bases the order on the taskSpec and the internally added Steps.

[Peaorl]

/unhold

[imjasonh]

/lgtm

[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

[GregDritschler]

/lgtm

[tekton-robot]

@GregDritschler: changing LGTM is restricted to collaborators

In response to this:

/lgtm

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.

[imjasonh]

/hold cancel