fix(pipeline-augment): scope PipelineRun match to Pipeline namespace

[seiya-koji]

Type of Change

• Bug fix
• New feature
• Refactoring
• Migration
• CVE Fix

Summary

augmentRunsToData() matched PipelineRuns to Pipelines using only the tekton.dev/pipeline label, without checking that the PipelineRun's namespace matches the Pipeline's namespace.
In the Pipelines list "All Projects" view, this caused every Pipeline with the same name across different namespaces to show the same "Last run", even when the PipelineRun only existed in one of those namespaces.

Fixes #1168

Fix: added a namespace equality check to the existing label match in augmentRunsToData.

Test plan:

• Added a regression test in pipeline-augment.spec.ts reproducing the bug: two Pipelines with the same name in different namespaces, only one of which has a matching PipelineRun. Confirmed it fails before the fix and passes after.
• Adjusted pre-existing test fixtures (pipeline-augment-test-data.ts) that had Pipeline/PipelineRun namespace mismatches, so they keep passing under the new namespace-aware matching.
• Ran the full test suite: all passing (1 pre-existing skip, unrelated to this change).
• eslint on changed files: no issues.

Screen Recordings / Screenshot

Before

Screen recordings for before/after.

Before: When a create-table Pipeline was run in only one namespace, every namespace that had a Pipeline with the same name showed that run — the create-table-ixlmy2 PipelineRun appeared across all of them, all with the same timestamp (Jul 10, 2026, 3:23 PM).

After this fix, only the namespace where the Pipeline actually ran shows a result — each namespace now shows its own PipelineRun.

[openshift-ci]

Hi @seiya-koji. Thanks for your PR.

I'm waiting for a openshift-pipelines 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.

Details

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-sigs/prow repository.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

[anwesha-palit-redhat]

Hi @seiya-koji 👋
Can you please add before / after screen recordings if possible ?

[anwesha-palit-redhat]

/ok-to-test

[seiya-koji]

@anwesha-palit-redhat
Added before/after screenshots to the PR description.

[seiya-koji]

FYI — this looks like an openshift/release-side issue, but flagging it here.

While testing this locally, yarn run start-console failed with useSearchParams/useNavigate is not a function.
It looks like quay.io/openshift/origin-console:latest is stuck on a 2026-02-14 build (pre-dates react-router v7).

The mirroring job that's supposed to update it has been failing on every run: https://prow.ci.openshift.org/job-history/gs/test-platform-results/logs/periodic-image-mirroring-openshift

[anwesha-palit-redhat]

Defect verification

Defect-verification.mov

Fix verification

Fix-verification.mov

[anwesha-palit-redhat]

/lgtm

[anwesha-palit-redhat]

@seiya-koji would you please mind cherry-picking this to main ?

[anwesha-palit-redhat]

/cherry-pick main

[openshift-cherrypick-robot]

@anwesha-palit-redhat: once the present PR merges, I will cherry-pick it on top of main in a new PR and assign it to you.

Details

In response to this:

/cherry-pick main

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-sigs/prow repository.

[seiya-koji]

@anwesha-palit-redhat I'm not too familiar with how this works — does this mean the bot will handle the cherry-pick automatically once this merges, and there's nothing I need to do on my end?
Or would it be better if I opened the PR against main myself?

[anwesha-palit-redhat]

@anwesha-palit-redhat I'm not too familiar with how this works — does this mean the bot will handle the cherry-pick automatically once this merges, and there's nothing I need to do on my end? Or would it be better if I opened the PR against main myself?

my bad, i did not explain it well, we will let this PR merge first
and then we will try the bot cherry-pick, but if it fails then would you be able to manually cherry-pick ? ( this was what i wanted to ask )

[seiya-koji]

Got it — if the bot cherry-pick fails, I'll open the PR against main manually.

[arvindk-softwaredev]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anwesha-palit-redhat, arvindk-softwaredev, seiya-koji

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [anwesha-palit-redhat,arvindk-softwaredev]

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

[openshift-cherrypick-robot]

@anwesha-palit-redhat: new pull request created: #1178

Details

In response to this:

/cherry-pick main

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-sigs/prow repository.