fix(taskrun): ensure status steps are ordered correctly when using StepAction #9039
+365
−24
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `TaskRun.Status.Steps` list was not guaranteed to reflect the true execution order when StepActions were involved. Steps populated earlier (from StepAction resolution) were left at the front, with inline steps appended later, causing a mismatch with the pod container order and confusing dashboards. This change fixes the issue by creating a temporary slice aligned with the (already sorted) pod step container sequence and then replace `trs.Steps` in one shot. We still preserve existing `Provenance` for matching steps by name.
…ns are used When at least one StepAction is referenced, `TaskRun.Status.Steps` is pre-populated to capture provenance for remote steps during resolution. However, inline steps were not included at that stage and only appeared later during pod-based status reconciliation. This contributed to confusing ordering and visibility for dashboards relying on `Status.Steps`. In the Tekton Dashboard specifically, StepAction-backed steps showed up first (because they were present in `Status.Steps` right after resolution), while inline steps appeared only after the pod was created and `MakeTaskRunStatus` had run to append them. This resulted in steps "popping" into view and reshuffling, which was confusing. When a `TaskRun` references at least one `StepAction`, in the resolution flow, the inline `Step` should also append an entry in `Status.Steps` even if it has no `Provenance`.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
The following is the coverage report on the affected files.
|
|
/retest |
|
/assign |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
When a
TaskRunreferencesStepActions,TaskRun.Status.Stepsis partially populated during resolution (to capture provenance). Later, pod-based status processing appends inline steps, which can result inStepActionsteps being shown first and inline steps last, regardless of the real pod order.This breaks dashboards and tools that assume
Status.Stepsreflects the true execution order:StepActionsteps appear first and inline steps are appended, regardless of their real execution order in the pod.Fixes #9037
Changes
This PR includes two complementary commits that address both completeness and ordering of Status.Steps.
setTaskRunStatusBasedOnStepStatusnow constructs a new ordered slice the size of the step container list and replacestrs.Stepsin one shot.stepStatuseswere already sorted to matchpod.Spec.Containers; we leverage that to ensure strict pod-order.GetStepActionsData, if at least oneStepActionis present in theTask, create aStepStatefor every step:StepActionsteps getProvenance.RefSourcewhen available.nilprovenance.Status.Stepscomplete earlier in the lifecycle, removing the Dashboard "popping" effect whereStepActionsteps appear first and inline steps arrive later.Release Notes