Story (Required)

As a developer/operator, trying to debug a failed pipeline step from a Git provider notification, I want a direct link to that specific step in the OpenShift Console so that I can immediately see the relevant logs without having to manually find the run and expand the correct step.

This feature improves the "inner loop" development experience by reducing the time and clicks required to diagnose a specific failure. When tools like Pipelines-as-Code (pac) report a failure in a Git PR comment, they can link directly to the point of failure, making the feedback loop much faster.

Background (Required)

Pipelines-as-Code (pac) provides detailed feedback on pipeline execution directly within the user's Git provider (e.g., GitHub, GitLab). Currently, when linking back to the OpenShift Console for log details, `pac` can only link to the top-level PipelineRun or TaskRun.

With the growing prominence of `StepActions` and more complex Tasks, individual steps are becoming more significant. Users need a way to navigate directly to a specific step's logs and status. This story proposes adding a deep-linking capability to the console to support this workflow, allowing external tools to construct a URL that opens the details page and automatically focuses on a specific step.

Out of scope

• This story does not include the work for `pac` or other tools to generate these new deep-link URLs. It only covers the console's ability to interpret them.
• This does not involve creating new APIs or modifying the backend. This is a front-end/UI routing enhancement.
• The fundamental appearance or functionality of the log viewer itself is not being changed.

Approach (Required)

The proposed approach is to use a URL query parameter to specify the target step.

1. Define a URL convention to include the step name. For example:
_Current URL: `/k8s/ns/<namespace>/tekton.dev~v1beta1~PipelineRun/<pipelinerun-name>/logs?taskName=<task-name>`
_Proposed URL: `/k8s/ns/<namespace>/tekton.dev~v1beta1~PipelineRun/<pipelinerun-name>/logs?taskName=<task-name>&step=<step-name>`

2. Update the OpenShift Console's front-end routing logic for the PipelineRun and TaskRun details pages to parse the `step` query parameter.

3. On page load, if the `step` parameter is present in the URL:

• The component will search for a step matching the provided name.
• If a match is found, the UI will automatically scroll to that step in the list and expand its details/log view.
• If no matching step is found, the page should load gracefully as it normally would, without displaying an error.

Dependencies

• While there are no blocking stories, the full value of this feature is realized when client tools (like Pipelines-as-Code) are updated to generate these deep links.

Acceptance Criteria (Mandatory)

• GIVEN I have a URL for a PipelineRun AND I append a valid query parameter `?step=<existing-step-name>`,
  WHEN I navigate to this URL in my browser,
  THEN the PipelineRun details page loads, automatically scrolls to the specified step, and expands its log viewer.

• GIVEN I have a URL for a TaskRun AND I append a valid query parameter `?step=<existing-step-name>`,
  WHEN I navigate to this URL in my browser,
  THEN the TaskRun details page loads, automatically scrolls to the specified step, and expands its log viewer.

• GIVEN I have a URL for a PipelineRun or TaskRun AND I append a query parameter for a step that does not exist (e.g., `?step=non-existent-step`),
  WHEN I navigate to this URL,
  THEN the page loads normally without error and without expanding any specific step.

• GIVEN I am viewing a PipelineRun or TaskRun details page,
  WHEN I manually click to expand or collapse a step,
  THEN the URL in the browser's address bar should not change.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• [ ] Code is completed, reviewed, documented and checked in
• [ ] Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• [ ] Continuous Delivery pipeline(s) is able to proceed with new code included
• [ ] Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• [ ] Acceptance criteria are met