SRVKP-8998: fix Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces #678

anwesha-palit-redhat · 2025-10-13T06:43:57Z

Description of the Problem

The customer experiences confusion and incorrect task configuration when editing pipelines through the Pipeline Builder UI.
Because the side panel displays stale or incorrect parameter data for tasks that share the same name across namespaces, users may unknowingly save or deploy pipelines with invalid configurations.
This leads to pipeline failures and loss of confidence in the UI’s reliability.

Workaround

A partial workaround exists:
Users can manually verify and edit the Pipeline YAML to ensure it references the correct task and parameters from the intended namespace.
However, this requires advanced Tekton knowledge and defeats the purpose of the visual builder — making it unsuitable for most users.

Versions

OCP Version: 4.16
Pipelines Operator Version: 1.17, 1.18

Steps to Reproduce

Create a task with a name identical to an existing task in the openshift-pipelines namespace.
Using the Pipeline Builder UI, create a new pipeline and add the task from the openshift-pipelines namespace.
Observe that the Pipeline Builder side panel shows parameters from the task in the current namespace instead of the selected one.
Check the YAML editor — it correctly references the task from the cluster resolver and displays the accurate parameter data.

Reproducibility

Yes, reproducible Always

Customer Impact

Customer Name: Jeffrey Luckett
Revenue Impact: Medium — misconfigured pipelines can lead to failed runs and CI/CD delays, increasing support overhead and reducing user trust in the console plugin UI.

Root Cause

In the previous implementation, installation of Artifact Hub tasks failed because tasks with the same names already existed in the cluster resolver or namespace.
As a result:

The data displayed in the Pipeline Builder form became stale.
When tasks were removed from the Pipeline Builder, the actual cluster task was not uninstalled.
Upon reinstalling a task with the same name, the old (stale) data persisted.

Fix Implemented

Added a check for existing tasks with the same name before installation.
If a conflict is found, a safe name is generated and used for creating a new task.
During task removal, the system:
- Checks if a task with the same name exists.
- If yes, uninstalls it to maintain data hygiene.
- If not, it updates the React state accordingly.

This ensures consistent task data and prevents stale or incorrect parameter references.

Screen Recordings

(Since GitHub upload size limits apply, videos are uploaded to Google Drive)

🎥 [Before Fix – Showcasing Issue]
🎥 [After Fix – Validation]

openshift-ci-robot · 2025-10-22T15:16:54Z

@anwesha-palit-redhat: This pull request references SRVKP-8998 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.21.0" version, but no target version was set.

In response to this:

Description of the Problem

The customer experiences confusion and incorrect task configuration when editing pipelines through the Pipeline Builder UI.
Because the side panel displays stale or incorrect parameter data for tasks that share the same name across namespaces, users may unknowingly save or deploy pipelines with invalid configurations.
This leads to pipeline failures and loss of confidence in the UI’s reliability.

Workaround

A partial workaround exists:
Users can manually verify and edit the Pipeline YAML to ensure it references the correct task and parameters from the intended namespace.
However, this requires advanced Tekton knowledge and defeats the purpose of the visual builder — making it unsuitable for most users.

Versions

OCP Version: 4.16

Pipelines Operator Version: 1.17, 1.18

Steps to Reproduce

Create a task with a name identical to an existing task in the openshift-pipelines namespace.

Using the Pipeline Builder UI, create a new pipeline and add the task from the openshift-pipelines namespace.

Observe that the Pipeline Builder side panel shows parameters from the task in the current namespace instead of the selected one.

Check the YAML editor — it correctly references the task from the cluster resolver and displays the accurate parameter data.

Reproducibility

Yes, reproducible Always

Customer Impact

Customer Name: Jeffrey Luckett

Revenue Impact: Medium — misconfigured pipelines can lead to failed runs and CI/CD delays, increasing support overhead and reducing user trust in the console plugin UI.

Root Cause

In the previous implementation, installation of Artifact Hub tasks failed because tasks with the same names already existed in the cluster resolver or namespace.
As a result:

The data displayed in the Pipeline Builder form became stale.

When tasks were removed from the Pipeline Builder, the actual cluster task was not uninstalled.

Upon reinstalling a task with the same name, the old (stale) data persisted.

Fix Implemented

Added a check for existing tasks with the same name before installation.

If a conflict is found, a safe name is generated and used for creating a new task.

During task removal, the system:

Checks if a task with the same name exists.

If yes, uninstalls it to maintain data hygiene.

If not, it updates the React state accordingly.

This ensures consistent task data and prevents stale or incorrect parameter references.

Screen Recordings

(Since GitHub upload size limits apply, videos are uploaded to Google Drive)

🎥 [Before Fix – Showcasing Issue]

🎥 [After Fix – Validation]

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 openshift-eng/jira-lifecycle-plugin repository.

jhadvig · 2025-10-31T17:22:03Z

src/components/catalog/apis/artifactHub.ts

 export const fetchArtifactHubTasks = async (
  query: string,
-  limit: number = 20,
+  limit = 20,


lets keep the type

This was a lint error, due to auto inference, so will switch it back

jhadvig · 2025-10-31T17:44:58Z

src/components/pipeline-builder/PipelineBuilderForm.tsx

+                      taskExists = true;
+                    } catch (error) {
+                      console.warn(
+                        `Error fetching Task as task does not exist ${taskName}, so safely deleting from PipelineBuilder`,


lets the the RC if its really 404

I think the whole onRemove() should be a callback... if anything then for a better readability

Done, thanks

jhadvig · 2025-10-31T17:49:19Z

src/components/pipeline-builder/PipelineBuilderForm.tsx

+                      );
+                    }
+                    if (taskExists) {
+                      await k8sDelete({


This risks deleting a user-managed Task that just happens to share the name. Shouldnt we delete Tasks that the builder installed in this flow, checking TektonTaskAnnotation.installedFrom ?

That’s a good point — Using installedFrom limits cleanup to builder-installed tasks, but users may also install or update tasks via CLI / YAML. In this case, they were installing tasks using CLI and then adding them via the builder.

Therefore, I implemented this as I felt a more general approach might be safer long term — one that ensures consistent cleanup while still protecting user-managed resources.

Updated it according to what is suggested

Updated according to what @vikram-raj suggested, i.e, revert to the original version and not to delete the tasks, only update the UI builder

jhadvig · 2025-10-31T17:57:21Z

src/components/task-quicksearch/PipelineQuickSearch.tsx

  useCleanupOnFailure(failedTasks, onUpdateTasks, taskGroup);

+  // Get all existing task names from taskGroup and installed tasks
+  const getExistingTaskNames = (): string[] => {


the current implementation does not count with duplicated names. I would suggest something like:

const taskNames = new Set<string>(); // Add all tasks currently in the builder [ ...taskGroup.tasks, ...taskGroup.finallyTasks, ...taskGroup.listTasks, ...taskGroup.loadingTasks, ...taskGroup.finallyListTasks, ].forEach((t) => { if (t?.name) taskNames.add(t.name); }); // Add installed catalog items (avoid duplicates) catalogService.items.forEach((catalogItem) => { const name = catalogItem.data?.metadata?.name; if (name) taskNames.add(name); }); return Array.from(taskNames); };

Done, thanks!

jhadvig · 2025-10-31T18:00:13Z

src/components/task-quicksearch/PipelineQuickSearch.tsx

-            ).catch(() =>
-              setFailedTasks([...failedTasks, item.data.task.name]),
-            );
+            // Checking if task with same name already exists, if yes then create with a different name to avoid conflict


nit: These two blocks are pretty much the same, just using a different model. Lets rather create a callback which will take the model and its parameters

Done, thanks

openshift-ci · 2025-10-31T18:00:21Z

@jhadvig: changing LGTM is restricted to collaborators

In response to this:

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.

…llation of tasks with name name

vikram-raj

/lgtm

openshift-ci · 2025-11-04T12:28:01Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anwesha-palit-redhat, vikram-raj

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~~ [vikram-raj]

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

anwesha-palit-redhat · 2025-11-19T04:00:57Z

/cherry-pick release-v1.20.x

anwesha-palit-redhat · 2025-11-19T04:01:05Z

/cherry-pick release-v1.19.x

openshift-cherrypick-robot · 2025-11-19T04:01:36Z

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

In response to this:

/cherry-pick release-v1.20.x

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.

openshift-cherrypick-robot · 2025-11-19T04:01:45Z

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

In response to this:

/cherry-pick release-v1.19.x

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.

anwesha-palit-redhat · 2025-11-20T08:01:11Z

/cherry-pick release-v1.18.x

anwesha-palit-redhat · 2025-11-20T08:01:20Z

/cherry-pick release-v1.17.x

openshift-cherrypick-robot · 2025-11-20T08:02:05Z

@anwesha-palit-redhat: #678 failed to apply on top of branch "release-v1.18.x":

Applying: fix: updated task creation logic in pipeline builder to support installation of tasks with name name
Using index info to reconstruct a base tree...
M	src/components/catalog/apis/artifactHub.ts
M	src/components/pipeline-builder/PipelineBuilderForm.tsx
M	src/components/quick-search/utils/quick-search-utils.tsx
M	src/components/task-quicksearch/PipelineQuickSearch.tsx
Falling back to patching base and 3-way merge...
Auto-merging src/components/task-quicksearch/PipelineQuickSearch.tsx
Auto-merging src/components/quick-search/utils/quick-search-utils.tsx
CONFLICT (content): Merge conflict in src/components/quick-search/utils/quick-search-utils.tsx
Auto-merging src/components/pipeline-builder/PipelineBuilderForm.tsx
Auto-merging src/components/catalog/apis/artifactHub.ts
CONFLICT (content): Merge conflict in src/components/catalog/apis/artifactHub.ts
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 fix: updated task creation logic in pipeline builder to support installation of tasks with name name

In response to this:

/cherry-pick release-v1.18.x

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.

openshift-cherrypick-robot · 2025-11-20T08:02:06Z

@anwesha-palit-redhat: #678 failed to apply on top of branch "release-v1.17.x":

Applying: fix: updated task creation logic in pipeline builder to support installation of tasks with name name
Using index info to reconstruct a base tree...
M	src/components/catalog/apis/artifactHub.ts
M	src/components/pipeline-builder/PipelineBuilderForm.tsx
M	src/components/quick-search/utils/quick-search-utils.tsx
M	src/components/task-quicksearch/PipelineQuickSearch.tsx
Falling back to patching base and 3-way merge...
Auto-merging src/components/task-quicksearch/PipelineQuickSearch.tsx
Auto-merging src/components/quick-search/utils/quick-search-utils.tsx
CONFLICT (content): Merge conflict in src/components/quick-search/utils/quick-search-utils.tsx
Auto-merging src/components/pipeline-builder/PipelineBuilderForm.tsx
Auto-merging src/components/catalog/apis/artifactHub.ts
CONFLICT (content): Merge conflict in src/components/catalog/apis/artifactHub.ts
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 fix: updated task creation logic in pipeline builder to support installation of tasks with name name

In response to this:

/cherry-pick release-v1.17.x

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.

anwesha-palit-redhat requested a review from vikram-raj October 13, 2025 06:43

openshift-ci bot requested review from lokanandaprabhu and vdemeester October 13, 2025 06:44

anwesha-palit-redhat force-pushed the fix/SRVKP-8998 branch from 47acb2a to 35a8268 Compare October 13, 2025 06:53

vikram-raj changed the title ~~fix: [SRVKP-8998] Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces~~ SRVKP-8998: fix Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces Oct 22, 2025

openshift-ci-robot added the jira/valid-reference label Oct 22, 2025

jhadvig suggested changes Oct 31, 2025

View reviewed changes

anwesha-palit-redhat force-pushed the fix/SRVKP-8998 branch from 35a8268 to e00cb08 Compare November 3, 2025 10:00

anwesha-palit-redhat requested a review from jhadvig November 3, 2025 10:01

fix: updated task creation logic in pipeline builder to support insta…

261eac7

…llation of tasks with name name

anwesha-palit-redhat force-pushed the fix/SRVKP-8998 branch from e00cb08 to 261eac7 Compare November 4, 2025 10:56

vikram-raj approved these changes Nov 4, 2025

View reviewed changes

openshift-ci bot assigned vikram-raj Nov 4, 2025

openshift-ci bot added the lgtm label Nov 4, 2025

openshift-ci bot added the approved label Nov 4, 2025

vikram-raj merged commit dc8cbc4 into openshift-pipelines:main Nov 4, 2025
4 of 7 checks passed

openshift-cherrypick-robot mentioned this pull request Nov 19, 2025

[release-v1.20.x] SRVKP-8998: fix Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces #805

Open

openshift-cherrypick-robot mentioned this pull request Nov 19, 2025

[release-v1.19.x] SRVKP-8998: fix Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces #806

Open

SRVKP-8998: fix Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces #678

SRVKP-8998: fix Pipeline Builder UI shows stale parameter data for tasks with same name across namespaces #678

Uh oh!

Conversation

anwesha-palit-redhat commented Oct 13, 2025

Description of the Problem

Workaround

Versions

Steps to Reproduce

Reproducibility

Customer Impact

Root Cause

Fix Implemented

Screen Recordings

Uh oh!

openshift-ci-robot commented Oct 22, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of the Problem

Workaround

Versions

Steps to Reproduce

Reproducibility

Customer Impact

Root Cause

Fix Implemented

Screen Recordings

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Oct 31, 2025

Uh oh!

vikram-raj left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci bot commented Nov 4, 2025

Uh oh!

Uh oh!

anwesha-palit-redhat commented Nov 19, 2025

Uh oh!

anwesha-palit-redhat commented Nov 19, 2025

Uh oh!

openshift-cherrypick-robot commented Nov 19, 2025

Uh oh!

openshift-cherrypick-robot commented Nov 19, 2025

Uh oh!

anwesha-palit-redhat commented Nov 20, 2025

Uh oh!

anwesha-palit-redhat commented Nov 20, 2025

Uh oh!

openshift-cherrypick-robot commented Nov 20, 2025

Uh oh!

openshift-cherrypick-robot commented Nov 20, 2025

Uh oh!

Reviewers

Assignees

Labels

openshift-ci-robot commented Oct 22, 2025 •

edited by openshift-ci bot

Loading