Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

fix(taskrun): ensure status steps are ordered correctly when using StepAction #9039

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
Loading
from
Open

fix(taskrun): ensure status steps are ordered correctly when using StepAction #9039

wants to merge 1 commit into from

Conversation

Maximilien-R
Copy link
Contributor

Context

When a TaskRun references StepActions, TaskRun.Status.Steps is partially populated during resolution (to capture provenance). Later, pod-based status processing appends inline steps, which can result in StepAction steps being shown first and inline steps last, regardless of the real pod order.

This breaks dashboards and tools that assume Status.Steps reflects the true execution order:

  • Incorrect ordering: StepAction steps appear first and inline steps are appended, regardless of their real execution order in the pod.
  • UI "popping": In the Tekton Dashboard, StepAction-backed steps show up immediately (post-resolution) while inline steps only appear later (after pod creation and status reconciliation). This causes steps to "pop" into view and reshuffle, which is confusing.

Fixes #9037

Changes

This PR includes two complementary commits that address both completeness and ordering of Status.Steps.

  • Commit n°1:
    • setTaskRunStatusBasedOnStepStatus now constructs a new ordered slice the size of the step container list and replaces trs.Steps in one shot.
    • The input stepStatuses were already sorted to match pod.Spec.Containers; we leverage that to ensure strict pod-order.
    • Provenance for matching steps (by name) is preserved.
  • Commit n°2:
    • During GetStepActionsData, if at least one StepAction is present in the Task, create a StepState for every step:
      • StepAction steps get Provenance.RefSource when available.
      • Inline steps get nil provenance.
    • This makes Status.Steps complete earlier in the lifecycle, removing the Dashboard "popping" effect where StepAction steps appear first and inline steps arrive later.

Release Notes

- `TaskRun.Status.Steps` now strictly follows the pod’s step container order.
- When `StepActions` are used, inline steps are also included in `TaskRun.Status.Steps` (with nil provenance) early, preventing steps from "popping" into view later and improving dashboard stability.

@tekton-robot tekton-robot added the release-note Denotes a PR that will be considered when it comes time to generate release notes. label Sep 19, 2025
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Sep 19, 2025
@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/pod/status.go 92.2% 92.4% 0.1

@waveywaves
Copy link
Member

/retest

@waveywaves waveywaves requested review from vdemeester and waveywaves and removed request for jerop September 23, 2025 17:26
@waveywaves
Copy link
Member

/assign

waveywaves
waveywaves requested changes Sep 29, 2025
View reviewed changes
Copy link
Member

@waveywaves waveywaves left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for this fix ! I have one performance fix, a comment suggestion and wanted to point that when not StepActions exist, StepStates won't get created considering that we are returning on lines 202-204 in taskspec.go. we should have StepStates created regardless for consistent behaviour right ?

pkg/pod/status.go Outdated Show resolved Hide resolved
pkg/reconciler/taskrun/resources/taskspec.go Outdated Show resolved Hide resolved
@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch from bb65aa8 to faa13e8 Compare September 30, 2025 10:56
@Maximilien-R
Copy link
Contributor Author

Hi @waveywaves 👋

I've taken your feedback into account and made the following changes:

  • added a lookup map for the step state provenances in setTaskRunStatusBasedOnStepStatus
  • added a comment for readability on updateTaskRunProvenance usages
  • added a third commit to populate TaskRun.Status.Steps in all scenarios (also in the case of inline steps only).

For the third commit, in absolute terms, when inline steps only, we don't have the issue I'm trying to solve; however, populating TaskRun.Status.Steps in this case has the advantage of having a consistent behaviour and will allow the UI to display the steps a little earlier (no need to wait for the pod to be created).

@tekton-robot
Copy link
Collaborator

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/pod/status.go 92.2% 92.4% 0.2

@waveywaves
Copy link
Member

/retest

@waveywaves
Copy link
Member

Thank you @Maximilien-R can you rebase the PR, there seems to be an issue with the CI

@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch from faa13e8 to 52a30a3 Compare October 1, 2025 07:13
@Maximilien-R
Copy link
Contributor Author

@waveywaves I did the rebase but the e2e tests still don't pass 😞

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 1, 2025
@vdemeester
Copy link
Member 

2025-10-01T07:45:58.1625444Z   step-perl:
2025-10-01T07:45:58.1625619Z     Container ID:  
2025-10-01T07:45:58.1626055Z     Image:         mirror.gcr.io/perl:devel-bullseye
2025-10-01T07:45:58.1626222Z     Image ID:      
2025-10-01T07:45:58.1626412Z     Port:          <none>
2025-10-01T07:45:58.1626621Z     Host Port:     <none>
2025-10-01T07:45:58.1626772Z     Command:
2025-10-01T07:45:58.1626987Z       /tekton/bin/entrypoint
2025-10-01T07:45:58.1627127Z     Args:
2025-10-01T07:45:58.1627288Z       -wait_file
2025-10-01T07:45:58.1627482Z       /tekton/run/6/out
2025-10-01T07:45:58.1627644Z       -post_file
2025-10-01T07:45:58.1627837Z       /tekton/run/7/out
2025-10-01T07:45:58.1628042Z       -termination_path
2025-10-01T07:45:58.1628230Z       /tekton/termination
2025-10-01T07:45:58.1628428Z       -step_metadata_dir
2025-10-01T07:45:58.1628642Z       /tekton/run/7/status
2025-10-01T07:45:58.1628813Z       -entrypoint
2025-10-01T07:45:58.1629060Z       /tekton/scripts/script-7-zgq5v
2025-10-01T07:45:58.1629201Z       --
2025-10-01T07:45:58.1629378Z     State:          Waiting
2025-10-01T07:45:58.1629612Z       Reason:       ImagePullBackOff
2025-10-01T07:45:58.1629788Z     Ready:          False

Hmm, are those images not available anymore ?

@vdemeester
Copy link
Member

/retest

@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch from 52a30a3 to b0f2db3 Compare October 3, 2025 15:09
@Maximilien-R
Copy link
Contributor Author

/kind bug

@tekton-robot tekton-robot added the kind/bug Categorizes issue or PR as related to a bug. label Oct 3, 2025
@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch 2 times, most recently from d5b6c91 to 4197b8f Compare October 7, 2025 09:18
@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch 2 times, most recently from 05d36d5 to 4d6af0b Compare October 7, 2025 11:59
@waveywaves waveywaves added this to the v1.6.0 (LTS) milestone Oct 7, 2025
@waveywaves
Copy link
Member

/retest

2 similar comments
@waveywaves
Copy link
Member

/retest

@waveywaves
Copy link
Member

/retest

@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch 3 times, most recently from 9d70974 to 1bbe20a Compare October 13, 2025 13:53
@afrittoli
Copy link
Member

@waveywaves if you are satisfied with the changes, could you remove the "requested change" from the PR?

@afrittoli
Copy link
Member

/retest

1 similar comment
@waveywaves
Copy link
Member

/retest

@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester, waveywaves

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 [vdemeester,waveywaves]

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

@Maximilien-R
fix(taskspec): ensure TaskRun.Status.Steps ordering matches pod execu…
73ff66e 
…tion order

The TaskRun.Status.Steps list was not guaranteed to reflect the true
execution order when StepActions were involved, causing confusing behavior
in dashboards like Tekton Dashboard where steps would appear to "pop" into
view and reshuffle.

This change addresses three related issues:
1. Steps populated from StepAction resolution appeared first in Status.Steps,
   while inline steps were only added later during pod-based status
   reconciliation, creating a mismatch with actual execution order.
2. When TaskRuns used StepActions, inline steps were missing from
   Status.Steps during the resolution phase, contributing to the ordering
   confusion.
3. The final Status.Steps ordering didn't match the pod container sequence,
   making it difficult for dashboards to display accurate step progression.

The fix ensures that:
- Status.Steps are populated for both StepAction-backed and inline steps
  during resolution, even when there is no StepActions involved
- The final Status.Steps ordering is aligned with the pod step container
  sequence by creating a temporary slice and replacing trs.Steps in one shot
- Existing Provenance information is preserved for matching steps by name
@Maximilien-R Maximilien-R force-pushed the fix-taskrun-status-steps-ordering branch from 1bbe20a to 73ff66e Compare October 17, 2025 08:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@vdemeester vdemeester vdemeester approved these changes

@waveywaves waveywaves waveywaves approved these changes

@abayer abayer Awaiting requested review from abayer

Assignees

@waveywaves waveywaves

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/bug Categorizes issue or PR as related to a bug. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

Tekton Community Roadmap
Status: Todo

Milestone

v1.6.0 (LTS)

Development

Successfully merging this pull request may close these issues.

TaskRun Status.Steps order incorrect when using StepAction

5 participants

@Maximilien-R @tekton-robot @waveywaves @vdemeester @afrittoli
Morty Proxy This is a proxified and sanitized view of the page, visit original site.