Skip to content

SRVKP-11799: tekton hub integration removal from pipelines console-plugin#1135

Open
arvindk-softwaredev wants to merge 1 commit into
openshift-pipelines:masterfrom
arvindk-softwaredev:feat/SRVKP-11799
Open

SRVKP-11799: tekton hub integration removal from pipelines console-plugin#1135
arvindk-softwaredev wants to merge 1 commit into
openshift-pipelines:masterfrom
arvindk-softwaredev:feat/SRVKP-11799

Conversation

@arvindk-softwaredev

@arvindk-softwaredev arvindk-softwaredev commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Removed all Tekton Hub integration code and consolidate the community task catalog to exclusively use Artifact Hub as the external task source.

Tekton Hub has been deprecated and this PR cleans up all references, APIs, types, models, and test data associated with it, replacing them with Artifact Hub equivalents where applicable.

Changes

Removed

  • Tekton Hub API layer (src/components/catalog/apis/tektonHub.ts) — all types, API calls (useTektonHubResources, getTektonHubTaskVersions, useInclusterTektonHubURLs), and constants (TEKTON_HUB_API_ENDPOINT, TEKTON_HUB_ENDPOINT)
  • Tekton Hub catalog provider (src/components/catalog/providers/useTekonHubTasksProvider.tsx) — the TektonHubTaskProvider and its normalization logic
  • TektonHub K8s model from src/models.ts and the corresponding console.model-metadata + console.catalog/item-provider entries from console-extensions.json
  • TektonHub type definitions (src/types/hub.ts) and test fixtures (src/test-data/tektonhub-data.ts)
  • Dead code — createTask, updateTask, getInstalledFromAnnotation, isTektonHubTaskWithoutVersions, filterBySupportedPlatforms, getClusterPlatform, and the TaskProviders.tektonHub enum value
  • Tekton Hub-specific tests (versions API tests, hub link tests)

Updated

  • useHubIntegration (renamed from useTektonHubIntegration) now returns [boolean, boolean] (integration status + loaded state), preventing Artifact Hub fetches before the TektonConfig is loaded
  • PipelineQuickSearch callback simplified — removed Tekton Hub branching; Artifact Hub tasks now lazily fetch content_url via getArtifactHubTaskDetails when a selected version URL isn't already cached
  • PipelineQuickSearchDetails — added detailsLoaded state to disable the CTA button while Artifact Hub details are being fetched; removed the "Read more" hub link; fixed the useEffect cleanup (returned proper cleanup function instead of commented-out code)
  • QuickSearchModalBody — fixed outside-click handler to ignore clicks inside the version dropdown (prevents accidental modal close)
  • quick-search-utils — reordered spread in handleCta so callbackProps overrides defaults (ensures the correct selectedVersion is passed)
  • PipelineQuickSearchVersionDropdown— replaced TektonHubTaskVersion type with a generic local TaskVersion type
  • getSelectedVersionUrl — now checks selectedVersionForContentUrl matches the requested version before returning the cached URL (prevents stale URL usage)
  • findInstalledTask — only matches tasks annotated as installed from Artifact Hub (removed Tekton Hub annotation check)
  • isInstalledNamespaceTask — annotation check updated from Tektonhub to ArtifactHub
  • HUB_INTEGRATION_KEY constant moved to src/consts.ts for shared access
  • Updated PAC repository template URL from hub.tekton.dev to artifacthub.io/packages/search
  • Community catalog description changed from "Browse tekton hub tasks" to "Browse community tasks"

Screen Recordings

SRVKP-11799-part1.mov
SRVKP-11799-part2.mov

@openshift-ci-robot

openshift-ci-robot commented Jun 19, 2026

Copy link
Copy Markdown
Collaborator

@arvindk-softwaredev: This pull request references SRVKP-11799 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 story to target the "5.0.0" version, but no target version was set.

Details

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

@openshift-ci openshift-ci Bot requested review from pratap0007 and vdemeester June 19, 2026 08:28
@openshift-ci

openshift-ci Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: arvindk-softwaredev

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 [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-ci openshift-ci Bot added the approved Label for Approved PRs label Jun 19, 2026
@qodo-code-review

qodo-code-review Bot commented Jun 19, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (1) 📜 Skill insights (0)

Grey Divider


Action required

1. Browse community tasks. missing locales 📘 Rule violation ⚙ Maintainability
Description
The catalogDescription was updated to use the i18n key `%plugin__pipelines-console-plugin~Browse
community tasks.% in console-extensions.json`, but only the English locale JSON defines the new
Browse community tasks. key while other locales still contain the old Browse tekton hub tasks.
entry. This suggests the generated i18n artifacts were not fully regenerated (e.g., via `yarn
i18n`), causing missing non-English translations and fallback to the English source string.
Code

console-extensions.json[R1461-1465]

  "properties": {
    "type": "Community",
    "title": "%plugin__pipelines-console-plugin~Community%",
-      "catalogDescription": "%plugin__pipelines-console-plugin~Browse tekton hub tasks.%"
+      "catalogDescription": "%plugin__pipelines-console-plugin~Browse community tasks.%"
  },
Evidence
PR Compliance ID 2 expects string changes to use the plugin i18n namespace and for translation
outputs to be regenerated when strings change; here, the PR updates console-extensions.json to
reference the new i18n key while only locales/en/plugin__pipelines-console-plugin.json includes
Browse community tasks.. Other locale bundles (explicitly including locales/es/..., and
similarly fr/ja/ko/zh) still contain only the prior Browse tekton hub tasks. key, demonstrating a
divergence between the referenced key and the available translations and proving that non-English
locales will not have a translated value for the new description.

AGENTS.md: UI String Changes Must Use the Plugin i18n Namespace and Regenerate Translation Files: AGENTS.md: UI String Changes Must Use the Plugin i18n Namespace and Regenerate Translation Files: AGENTS.md: UI String Changes Must Use the Plugin i18n Namespace and Regenerate Translation Files: AGENTS.md: UI String Changes Must Use the Plugin i18n Namespace and Regenerate Translation Files
console-extensions.json[1460-1465]
locales/en/plugin__pipelines-console-plugin.json[76-82]
locales/es/plugin__pipelines-console-plugin.json[78-83]
locales/fr/plugin__pipelines-console-plugin.json[78-83]
console-extensions.json[1459-1465]
locales/es/plugin__pipelines-console-plugin.json[73-83]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A translatable UI string for the Community catalog item description was changed in `console-extensions.json`, but the generated locale JSON artifacts were not updated across all locales, leaving non-English bundles without the new `Browse community tasks.` key.
## Issue Context
`console-extensions.json` now references `%plugin__pipelines-console-plugin~Browse community tasks.%` for the Community `catalogDescription`. Only `locales/en/plugin__pipelines-console-plugin.json` defines `Browse community tasks.`, while other locale JSONs still only contain the previous key `Browse tekton hub tasks.`, so the new description won’t be translated outside English and will fall back to the English source string.
To resolve this, either regenerate i18n outputs (e.g., via `yarn i18n`) so all locale bundles include the updated key, or revert the key change in `console-extensions.json` to continue using the already-translated existing key if that’s preferred.
## Fix Focus Areas
- console-extensions.json[1459-1465]
- locales/en/plugin__pipelines-console-plugin.json[76-82]
- locales/es/plugin__pipelines-console-plugin.json[73-83]
- locales/fr/plugin__pipelines-console-plugin.json[78-83]
- locales/ja/plugin__pipelines-console-plugin.json[78-83]
- locales/ko/plugin__pipelines-console-plugin.json[78-83]
- locales/zh/plugin__pipelines-console-plugin.json[78-83]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Selected version URL regresses 🐞 Bug ≡ Correctness
Description
getSelectedVersionUrl now returns a URL only when attributes.selectedVersionForContentUrl matches
the requested version, but no code in the PR sets selectedVersionForContentUrl and the updated test
sets only selectedVersionContentUrl. This makes getSelectedVersionUrl return null for the new test
fixture and causes PipelineQuickSearch to always fall back to getArtifactHubTaskDetails on CTA
clicks.
Code

src/components/task-quicksearch/pipeline-quicksearch-utils.ts[R110-114]

+  if (item.attributes.selectedVersionForContentUrl !== version) {
+    return null;
+  }
+
+  return item.attributes.selectedVersionContentUrl ?? null;
Evidence
The helper now requires a new attribute (selectedVersionForContentUrl) to match the requested
version, but the code that populates the content URL does not set that attribute, and the updated
test expects the URL to be returned without it. PipelineQuickSearch’s CTA handler explicitly falls
back to calling ArtifactHub details when getSelectedVersionUrl returns null.

src/components/task-quicksearch/pipeline-quicksearch-utils.ts[103-115]
src/components/task-quicksearch/tests/pipeline-quicksearch-utils.spec.ts[244-266]
src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[61-74]
src/components/task-quicksearch/PipelineQuickSearch.tsx[128-142]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getSelectedVersionUrl()` now requires `item.attributes.selectedVersionForContentUrl === version` but no call site sets `selectedVersionForContentUrl`. As a result, the helper always returns `null` for items that only populate `selectedVersionContentUrl` (including the updated unit test), and the PipelineQuickSearch CTA path always triggers an extra ArtifactHub details fetch.
### Issue Context
- `PipelineQuickSearchDetails` sets `selectedVersionContentUrl` from ArtifactHub details responses, but does not record which version that URL corresponds to.
- The updated unit test expects `getSelectedVersionUrl()` to return the URL when only `selectedVersionContentUrl` is set.
### Fix Focus Areas
- src/components/task-quicksearch/pipeline-quicksearch-utils.ts[103-115]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[61-74]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[89-105]
- src/components/task-quicksearch/PipelineQuickSearch.tsx[128-142]
- src/components/task-quicksearch/__tests__/pipeline-quicksearch-utils.spec.ts[244-266]
### What to change
1. Whenever setting `selectedVersionContentUrl`, also set `selectedVersionForContentUrl` to the version it was fetched for (both initial-load and dropdown-change paths).
2. In `PipelineQuickSearch.tsx`, after fetching `details.content_url`, persist it back onto the item (`selectedVersionContentUrl` + `selectedVersionForContentUrl`) so subsequent clicks can reuse it.
3. Update the unit test to set `selectedVersionForContentUrl` along with `selectedVersionContentUrl` (or adjust `getSelectedVersionUrl` semantics if you intentionally don’t want the guard).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

3. Stale details overwrite 🐞 Bug ≡ Correctness ⭐ New
Description
PipelineQuickSearchDetails updates versions/tags and selectedVersionContentUrl after
getArtifactHubTaskDetails resolves without checking the item is still the currently selected one. If
the user changes the selected item while a request is in flight (e.g., ArrowUp/ArrowDown in the
modal), stale results can overwrite the newly selected item’s details/versions and confuse
subsequent CTA behavior.
Code

src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[R65-86]

    (key) => {
      setSelectedVersion(key);
      if (isArtifactHubTask(selectedItem)) {
+        setDetailsLoaded(false);
        getArtifactHubTaskDetails(selectedItem, key, isDevConsoleProxyAvailable)
          .then((item) => {
            selectedItem.attributes.versions = item.available_versions;
            selectedItem.attributes.selectedVersionContentUrl =
              item.content_url;
+            selectedItem.attributes.selectedVersionForContentUrl = key;
            selectedItem.tags = item.keywords;

            setVersions([...item.available_versions]);
            setHasInstalledVersion(isOneVersionInstalled(selectedItem));
+            setDetailsLoaded(true);
          })
          .catch((err) => {
            // eslint-disable-next-line no-console
            console.warn('Error while getting ArtifactHub Task details:', err);
            resetVersions();
+            setDetailsLoaded(true);
          });
Evidence
The version-change handler applies async results directly to selectedItem and component state,
while the modal supports changing selectedItem with arrow keys without necessarily unmounting the
details component—so stale requests can race and apply to the wrong active selection.

src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[64-90]
src/components/quick-search/QuickSearchModalBody.tsx[261-301]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`PipelineQuickSearchDetails` performs async Artifact Hub detail fetches that mutate `selectedItem` and set local state when they resolve, but does not verify the response corresponds to the currently-selected item.

### Issue Context
The quick search modal allows changing the selected item via keyboard navigation while details are shown. An in-flight request for the previous item/version can resolve after selection changes and overwrite the current details.

### Fix Focus Areas
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[64-133]

### Suggested fix
- Introduce a `useRef` request token / selected UID guard.
 - Example: increment `requestIdRef.current` before each fetch; capture `const req = requestIdRef.current;` and only apply results if `req === requestIdRef.current` and `selectedItem.uid` still matches the UID captured at request start.
- Apply the same guard to both:
 - the initial details load in `useEffect`
 - the per-version load in `onChangeVersion`
- Optionally cancel the lodash `debounce` on cleanup (`debouncedLoadDetails.cancel()`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Stale proxy flag usage 🐞 Bug ☼ Reliability ⭐ New
Description
PipelineQuickSearchDetails uses isDevConsoleProxyAvailable inside onChangeVersion and the
details-loading useEffect but omits it from both dependency arrays. If the DEVCONSOLE_PROXY flag
value changes after mount (flags resolving asynchronously), the component can keep calling the wrong
Artifact Hub endpoint path.
Code

src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[R65-88]

    (key) => {
      setSelectedVersion(key);
      if (isArtifactHubTask(selectedItem)) {
+        setDetailsLoaded(false);
        getArtifactHubTaskDetails(selectedItem, key, isDevConsoleProxyAvailable)
          .then((item) => {
            selectedItem.attributes.versions = item.available_versions;
            selectedItem.attributes.selectedVersionContentUrl =
              item.content_url;
+            selectedItem.attributes.selectedVersionForContentUrl = key;
            selectedItem.tags = item.keywords;

            setVersions([...item.available_versions]);
            setHasInstalledVersion(isOneVersionInstalled(selectedItem));
+            setDetailsLoaded(true);
          })
          .catch((err) => {
            // eslint-disable-next-line no-console
            console.warn('Error while getting ArtifactHub Task details:', err);
            resetVersions();
+            setDetailsLoaded(true);
          });
      }
    },
Evidence
PipelineQuickSearchDetails uses the flag within async fetch logic but does not re-run/recreate
callbacks when it changes; elsewhere in the repo, effects that depend on this flag include it in
their dependency arrays.

src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[64-90]
src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[92-133]
src/components/hooks/useTektonResults.ts[19-65]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
React hooks in `PipelineQuickSearchDetails` capture `isDevConsoleProxyAvailable` but do not list it as a dependency, causing stale closures.

### Issue Context
The value changes the code path inside `getArtifactHubTaskDetails`, so missing dependencies can lead to incorrect networking behavior.

### Fix Focus Areas
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[64-90]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[92-133]

### Suggested fix
- Add `isDevConsoleProxyAvailable` to:
 - the `useCallback` dependency list for `onChangeVersion`
 - the `useEffect` dependency list that triggers initial details load
- Ensure lint/CI expectations remain satisfied.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Dropped failedTasks entries 🐞 Bug ☼ Reliability ⭐ New
Description
PipelineQuickSearch appends to failedTasks using setFailedTasks([...failedTasks, name]) from async
catch handlers, which can lose earlier failures due to stale state closures. Lost entries can
prevent useCleanupOnFailure from detecting failures and converting failed loading tasks back,
leaving the builder in an inconsistent state.
Code

src/components/task-quicksearch/PipelineQuickSearch.tsx[R170-176]

+              ).catch((error) => {
+                console.warn(
+                  'Error updating ArtifactHub task - callsite PipelineQuickSearch:',
+                  error,
+                );
+                setFailedTasks([...failedTasks, item.data.task.name]);
+              });
Evidence
The async catch handler closes over failedTasks and uses a non-functional update, while cleanup
logic depends on the completeness of failedTasks to trigger conversions of failed loading tasks.

src/components/task-quicksearch/PipelineQuickSearch.tsx[89-110]
src/components/task-quicksearch/PipelineQuickSearch.tsx[163-176]
src/components/pipeline-builder/hooks.ts[497-521]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`setFailedTasks([...failedTasks, ...])` in async handlers can drop updates when multiple failures occur close together.

### Issue Context
`useCleanupOnFailure` relies on `failedTasks.includes(...)` to perform cleanup actions.

### Fix Focus Areas
- src/components/task-quicksearch/PipelineQuickSearch.tsx[89-110]
- src/components/task-quicksearch/PipelineQuickSearch.tsx[163-176]
- src/components/pipeline-builder/hooks.ts[497-521]

### Suggested fix
- Replace all async-path updates like:
 - `setFailedTasks([...failedTasks, name])`
 with:
 - `setFailedTasks((prev) => [...prev, name])`
- Do this consistently for:
 - `updateArtifactHubTask(...).catch(...)`
 - task creation catch paths in `handleTaskCreationWithNameConflict` and any other async catch blocks in the component.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit 7978623

Results up to commit N/A


🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)


Action required
1. Browse community tasks. missing locales 📘 Rule violation ⚙ Maintainability
Description
The catalogDescription was updated to use the i18n key `%plugin__pipelines-console-plugin~Browse
community tasks.% in console-extensions.json`, but only the English locale JSON defines the new
Browse community tasks. key while other locales still contain the old Browse tekton hub tasks.
entry. This suggests the generated i18n artifacts were not fully regenerated (e.g., via `yarn
i18n`), causing missing non-English translations and fallback to the English source string.
Code

console-extensions.json[R1461-1465]

   "properties": {
     "type": "Community",
     "title": "%plugin__pipelines-console-plugin~Community%",
-      "catalogDescription": "%plugin__pipelines-console-plugin~Browse tekton hub tasks.%"
+      "catalogDescription": "%plugin__pipelines-console-plugin~Browse community tasks.%"
   },
Evidence
PR Compliance ID 2 expects string changes to use the plugin i18n namespace and for translation
outputs to be regenerated when strings change; here, the PR updates console-extensions.json to
reference the new i18n key while only locales/en/plugin__pipelines-console-plugin.json includes
Browse community tasks.. Other locale bundles (explicitly including locales/es/..., and
similarly fr/ja/ko/zh) still contain only the prior Browse tekton hub tasks. key, demonstrating a
divergence between the referenced key and the available translations and proving that non-English
locales will not have a translated value for the new description.

AGENTS.md: UI String Changes Must Use the Plugin i18n Namespace and Regenerate Translation Files: AGENTS.md: UI String Changes Must Use the Plugin i18n Namespace and Regenerate Translation Files
console-extensions.json[1460-1465]
locales/en/plugin__pipelines-console-plugin.json[76-82]
locales/es/plugin__pipelines-console-plugin.json[78-83]
locales/fr/plugin__pipelines-console-plugin.json[78-83]
console-extensions.json[1459-1465]
locales/es/plugin__pipelines-console-plugin.json[73-83]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A translatable UI string for the Community catalog item description was changed in `console-extensions.json`, but the generated locale JSON artifacts were not updated across all locales, leaving non-English bundles without the new `Browse community tasks.` key.
## Issue Context
`console-extensions.json` now references `%plugin__pipelines-console-plugin~Browse community tasks.%` for the Community `catalogDescription`. Only `locales/en/plugin__pipelines-console-plugin.json` defines `Browse community tasks.`, while other locale JSONs still only contain the previous key `Browse tekton hub tasks.`, so the new description won’t be translated outside English and will fall back to the English source string.
To resolve this, either regenerate i18n outputs (e.g., via `yarn i18n`) so all locale bundles include the updated key, or revert the key change in `console-extensions.json` to continue using the already-translated existing key if that’s preferred.
## Fix Focus Areas
- console-extensions.json[1459-1465]
- locales/en/plugin__pipelines-console-plugin.json[76-82]
- locales/es/plugin__pipelines-console-plugin.json[73-83]
- locales/fr/plugin__pipelines-console-plugin.json[78-83]
- locales/ja/plugin__pipelines-console-plugin.json[78-83]
- locales/ko/plugin__pipelines-console-plugin.json[78-83]
- locales/zh/plugin__pipelines-console-plugin.json[78-83]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Selected version URL regresses 🐞 Bug ≡ Correctness
Description
getSelectedVersionUrl now returns a URL only when attributes.selectedVersionForContentUrl matches
the requested version, but no code in the PR sets selectedVersionForContentUrl and the updated test
sets only selectedVersionContentUrl. This makes getSelectedVersionUrl return null for the new test
fixture and causes PipelineQuickSearch to always fall back to getArtifactHubTaskDetails on CTA
clicks.
Code

src/components/task-quicksearch/pipeline-quicksearch-utils.ts[R110-114]

+  if (item.attributes.selectedVersionForContentUrl !== version) {
+    return null;
+  }
+
+  return item.attributes.selectedVersionContentUrl ?? null;
Evidence
The helper now requires a new attribute (selectedVersionForContentUrl) to match the requested
version, but the code that populates the content URL does not set that attribute, and the updated
test expects the URL to be returned without it. PipelineQuickSearch’s CTA handler explicitly falls
back to calling ArtifactHub details when getSelectedVersionUrl returns null.

src/components/task-quicksearch/pipeline-quicksearch-utils.ts[103-115]
src/components/task-quicksearch/tests/pipeline-quicksearch-utils.spec.ts[244-266]
src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[61-74]
src/components/task-quicksearch/PipelineQuickSearch.tsx[128-142]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getSelectedVersionUrl()` now requires `item.attributes.selectedVersionForContentUrl === version` but no call site sets `selectedVersionForContentUrl`. As a result, the helper always returns `null` for items that only populate `selectedVersionContentUrl` (including the updated unit test), and the PipelineQuickSearch CTA path always triggers an extra ArtifactHub details fetch.
### Issue Context
- `PipelineQuickSearchDetails` sets `selectedVersionContentUrl` from ArtifactHub details responses, but does not record which version that URL corresponds to.
- The updated unit test expects `getSelectedVersionUrl()` to return the URL when only `selectedVersionContentUrl` is set.
### Fix Focus Areas
- src/components/task-quicksearch/pipeline-quicksearch-utils.ts[103-115]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[61-74]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[89-105]
- src/components/task-quicksearch/PipelineQuickSearch.tsx[128-142]
- src/components/task-quicksearch/__tests__/pipeline-quicksearch-utils.spec.ts[244-266]
### What to change
1. Whenever setting `selectedVersionContentUrl`, also set `selectedVersionForContentUrl` to the version it was fetched for (both initial-load and dropdown-change paths).
2. In `PipelineQuickSearch.tsx`, after fetching `details.content_url`, persist it back onto the item (`selectedVersionContentUrl` + `selectedVersionForContentUrl`) so subsequent clicks can reuse it.
3. Update the unit test to set `selectedVersionForContentUrl` along with `selectedVersionContentUrl` (or adjust `getSelectedVersionUrl` semantics if you intentionally don’t want the guard).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

Comment thread console-extensions.json
Comment on lines +110 to +114
if (item.attributes.selectedVersionForContentUrl !== version) {
return null;
}

return item.attributes.selectedVersionContentUrl ?? null;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

2. Selected version url regresses 🐞 Bug ≡ Correctness

getSelectedVersionUrl now returns a URL only when attributes.selectedVersionForContentUrl matches
the requested version, but no code in the PR sets selectedVersionForContentUrl and the updated test
sets only selectedVersionContentUrl. This makes getSelectedVersionUrl return null for the new test
fixture and causes PipelineQuickSearch to always fall back to getArtifactHubTaskDetails on CTA
clicks.
Agent Prompt
### Issue description
`getSelectedVersionUrl()` now requires `item.attributes.selectedVersionForContentUrl === version` but no call site sets `selectedVersionForContentUrl`. As a result, the helper always returns `null` for items that only populate `selectedVersionContentUrl` (including the updated unit test), and the PipelineQuickSearch CTA path always triggers an extra ArtifactHub details fetch.

### Issue Context
- `PipelineQuickSearchDetails` sets `selectedVersionContentUrl` from ArtifactHub details responses, but does not record which version that URL corresponds to.
- The updated unit test expects `getSelectedVersionUrl()` to return the URL when only `selectedVersionContentUrl` is set.

### Fix Focus Areas
- src/components/task-quicksearch/pipeline-quicksearch-utils.ts[103-115]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[61-74]
- src/components/task-quicksearch/PipelineQuickSearchDetails.tsx[89-105]
- src/components/task-quicksearch/PipelineQuickSearch.tsx[128-142]
- src/components/task-quicksearch/__tests__/pipeline-quicksearch-utils.spec.ts[244-266]

### What to change
1. Whenever setting `selectedVersionContentUrl`, also set `selectedVersionForContentUrl` to the version it was fetched for (both initial-load and dropdown-change paths).
2. In `PipelineQuickSearch.tsx`, after fetching `details.content_url`, persist it back onto the item (`selectedVersionContentUrl` + `selectedVersionForContentUrl`) so subsequent clicks can reuse it.
3. Update the unit test to set `selectedVersionForContentUrl` along with `selectedVersionContentUrl` (or adjust `getSelectedVersionUrl` semantics if you intentionally don’t want the guard).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

addressed in latest commit

@qodo-code-review qodo-code-review Bot added documentation Improvements or additions to documentation enhancement New feature or request Tests labels Jun 19, 2026
@arvindk-softwaredev arvindk-softwaredev marked this pull request as draft June 19, 2026 14:16
@arvindk-softwaredev arvindk-softwaredev marked this pull request as ready for review June 22, 2026 08:23
@openshift-ci openshift-ci Bot requested a review from pratap0007 June 22, 2026 08:23
@arvindk-softwaredev arvindk-softwaredev removed the request for review from pratap0007 June 22, 2026 08:26
@qodo-code-review

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 7978623

const target = e.target as HTMLElement;
const modalBody = ref.current?.parentElement;
/*Fix to avoid modal close on select of version dropdown*/
if (target.closest?.('.opp-quick-search-details__version-dropdown'))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: let us update the classname to something specific to OSP console plugin ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

updated to use id selector specific to OSP console plugin

Comment thread src/components/catalog/catalog-utils.ts

@anwesha-palit-redhat anwesha-palit-redhat left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

/lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Label for Approved PRs documentation Improvements or additions to documentation enhancement New feature or request jira/valid-reference Tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants