Expected Behavior

The steps contained in the TaskRuns status should follow the order of the container steps, as defined by #3679.

Actual Behavior

When a TaskRun includes steps that reference a StepAction, these steps are always at the top of the TaskRun's status step list, which doesn't always follow the order of steps defined in the container.

This behaviour causes display issues on the Tekton dashboard. The dashboard lists TaskRun's steps based on the steps defined in the TaskRuns status.

In case a TaskRun includes steps that reference a StepAction, this can cause two issues:

1. Incorrect step ordering: Steps referring to StepAction are always displayed at the top of the TaskRun steps list, regardless of their actual order defined in the container. This creates confusion about the actual flow of execution.
2. Misplaced step status: When a step fails, the status information is sometimes misplaced, leading to poor visibility on which steps actually failed. This makes debugging and troubleshooting difficult for users trying to understand TaskRun execution failures.

Additional Info

• Tekton Pipeline version: v1.4.0
• Tekton Dashboard version: v0.61.0
• Kubernetes version:

  Client Version: v1.32.2
  Kustomize Version: v5.5.0
  Server Version: v1.33.4-gke.1036000
  

Investigation

According to my analysis, when a TaskRun references a StepAction, when resolving the StepAction of the TaskRun, the Status.Steps field is populated to provide the Provenance of each resolved StepAction.

The pod is then created and we begin calling the MakeTaskRunStatus function with the created pod containing the steps in the expected order. However, the setTaskRunStatusBasedOnStepStatus function, which is supposed to order the steps of Status.Steps according to the container's order, only updates the provenance for known steps and adds unknown steps to the end of the slice. Meaning, our resolved StepAction which have populated Status.Steps will at the beginning of the slice and the inline steps for which we do not create an entry in Status.Steps are added at the end.

Fixes

I see at least two (non-exclusive) options to fix this issue:

1. If setTaskRunStatusBasedOnStepStatus should really ensure that the steps in Status.Steps follow the order defined in the container, then we should perhaps create a temporary slice of orderedStatusSteps that will be assigned to the TaskRun at the end.
2. When a TaskRun references at least one StepAction, in the resolution flow, the inline Step should also append an entry in Status.Steps here even if it has no Provenance.

Note: However, I don't know if these changes might have side effects that I haven't identified.

If needed, I am willing to contribute if the maintainers do not have time for it.