fix: update plugins in default configuration based on the content of the next DPDY

[rm3l]

Target branch

• I have verified this PR targets the correct branch (see branching strategy)

Description

Update plugin references in default configuration, matching what's available in the next catalog index image.

Which issue(s) does this PR fix or relate to

—

PR acceptance criteria

• Tests updated and passing
• Documentation updated
• Built-in TechDocs updated if needed. Note that TechDocs changes may need to be reviewed by a Product Manager and/or Architect to ensure content accuracy, clarity, and alignment with user needs.

How to test changes / Special notes to the reviewer

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rm3l]

/agentic_review

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 🔗 Cross-repo conflicts (3) 📜 Skill insights (0)

Context used

✅ Cross-repo context

  Explored: repo: redhat-developer/rhdh (sha: e3b3f0bc)

  Explored: repo: redhat-developer/rhdh-plugins (sha: 234bc786)

1. Lightspeed images still pulled 🐞 Bug ☼ Reliability ⭐ New

Description

configs/dynamic-plugins/dynamic-plugins.yaml now disables both Lightspeed dynamic plugins by
default, but the CI composite action still runs compose up for the full project, so the
Lightspeed/RAG services in compose.yaml are still pulled/started. This keeps CI/local startup
coupled to those images (and their availability) even though Lightspeed is disabled at the plugin
layer.

Code

configs/dynamic-plugins/dynamic-plugins.yaml[R45-47]

+  # TODO: re-enable this once the catalog index is stabilized
  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed:{{inherit}}'
-    disabled: false
+    disabled: true

Relevance

●● Moderate

Decoupling compose services from disabled plugins is non-trivial; team has adjusted Lightspeed CI
coverage before, unclear here.

PR-#229

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR disables Lightspeed plugins, but CI still executes compose up without filtering services,
and compose.yaml defines the Lightspeed/RAG services unconditionally—so those images/services remain
part of the default startup path despite Lightspeed being disabled.

configs/dynamic-plugins/dynamic-plugins.yaml[44-52]
compose.yaml[76-130]
.github/actions/rhdh-local-compose-test/action.yaml[269-279]

Agent prompt

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

### Issue description
Lightspeed plugins are disabled by default, but `docker/podman compose up` in CI still starts the full set of services from `compose.yaml`, including Lightspeed/RAG containers. This means disabling Lightspeed plugins does not remove the dependency on pulling/starting those images.

### Issue Context
- The PR flips both Lightspeed plugin entries to `disabled: true`.
- The CI composite action starts the whole compose project (`compose up ...`) without selecting services.
- `compose.yaml` defines `rag-init` and `lightspeed-core` as normal services (no `profiles:`).

### Fix Focus Areas
- configs/dynamic-plugins/dynamic-plugins.yaml[44-52]
- compose.yaml[76-130]
- .github/actions/rhdh-local-compose-test/action.yaml[269-279]

### Suggested fix
1. Add `profiles: ["lightspeed"]` (or similar) to `rag-init` and `lightspeed-core` in `compose.yaml`.
2. Ensure only Lightspeed-enabled scenarios activate the profile (e.g., add `--profile lightspeed` only when Lightspeed plugins are enabled, or move Lightspeed services into a separate compose file that is only included when needed).
3. (Optional) Document the profile usage in the Lightspeed docs / local guide so users can opt-in explicitly.

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

---

2. {{inherit}} may hard-fail 🔗 Cross-repo conflict ☼ Reliability ⭐ New

Description

configs/dynamic-plugins/dynamic-plugins.yaml now uses :{{inherit}} for some OCI packages;
rhdh-plugins install-dynamic-plugins throws if no matching OCI plugin key exists in an included
config (typically the catalog index image’s dynamic-plugins.default.yaml). If the catalog index
declares these plugins differently (e.g., dist-path instead of OCI, or different OCI image ref),
rhdh-local boot/install can fail.

Code

configs/dynamic-plugins/dynamic-plugins.yaml[R9-10]

+  - package: 'oci://quay.io/rhdh/backstage-community-plugin-tech-radar:{{inherit}}'
    disabled: false

Relevance

●● Moderate

Uses {{inherit}} already in repo configs; risk depends on catalog index contents, no close precedent
on hard-fail.

PR-#212

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

rhdh-local introduces :{{inherit}} OCI package refs. In rhdh-plugins, the merger throws when
{{inherit}} is used but no existing matching OCI key was merged from included configs, and the
RHDH docs explicitly call out this error condition. Additionally, rhdh’s catalog index tooling
documents that the index can declare either OCI refs or ./dynamic-plugins/dist/... refs, which
would not satisfy an OCI {{inherit}} lookup.

configs/dynamic-plugins/dynamic-plugins.yaml[1-18]
External repo: redhat-developer/rhdh-plugins, workspaces/install-dynamic-plugins/packages/install-dynamic-plugins/src/merger.ts [185-205]
External repo: redhat-developer/rhdh, docs/dynamic-plugins/installing-plugins.md [174-207]
External repo: redhat-developer/rhdh, e2e-tests/local-harness/catalog-index-refs.sh [7-10]

Agent prompt

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

### Issue description
`{{inherit}}` only works when the included config already defines the same OCI image key (same image ref + plugin path), otherwise install-dynamic-plugins throws and startup can fail.

### Issue Context
In `rhdh-plugins` install-dynamic-plugins, `{{inherit}}` is resolved strictly against previously-merged plugins. The catalog index image can also declare plugins as `./dynamic-plugins/dist/...` (not OCI), in which case an OCI `:{{inherit}}` override cannot inherit.

### Fix Focus Areas
- configs/dynamic-plugins/dynamic-plugins.yaml[8-18]

### What to change
- Verify the catalog index image’s `dynamic-plugins.default.yaml` contains matching OCI entries for the `:{{inherit}}` plugins you enable here.
- If it does not, either:
 - switch these entries to explicit tags/digests (remove `{{inherit}}`), or
 - change the package refs to exactly match the index’s OCI image references (registry/paths) so `{{inherit}}` can resolve.

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

---

3. OCI refs omit plugin path 🔗 Cross-repo conflict ≡ Correctness ⭐ New

Description

Several oci://... package refs (notably export-overlays) omit the !<plugin-path> suffix;
rhdh-plugins install-dynamic-plugins auto-detection only works if the OCI image contains exactly
one dynamic package, otherwise it throws and requires !<plugin-name>. If any of these referenced
images are multi-plugin, rhdh-local CI/local boot will fail until the config is updated to include
explicit !<plugin-path> values.

Code

configs/dynamic-plugins/dynamic-plugins.yaml[R25-26]

+  - package: 'oci://ghcr.io/redhat-developer/rhdh-plugin-export-overlays/red-hat-developer-hub-backstage-plugin-extensions:bs_1.52.0__0.19.1'
    disabled: false

Relevance

●● Moderate

Potential install-dynamic-plugins failure only if images are multi-plugin; no repo precedent
requiring !<plugin-path>.

PR-#212

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR config introduces path-less OCI refs for export-overlays images. In rhdh-plugins
install-dynamic-plugins, missing !path triggers auto-detect; if more than one plugin is found in
the OCI manifest annotation, it throws with instructions to specify !<plugin-name>. The CI
composite action also adds a path-less export-overlays ref, so the same behavior applies there.

configs/dynamic-plugins/dynamic-plugins.yaml[12-30]
.github/actions/rhdh-local-compose-test/action.yaml[221-233]
External repo: redhat-developer/rhdh-plugins, workspaces/install-dynamic-plugins/packages/install-dynamic-plugins/src/oci-key.ts [84-132]

Agent prompt

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

### Issue description
OCI package refs without `!<plugin-path>` rely on auto-detection. install-dynamic-plugins throws when the OCI image advertises multiple dynamic packages, requiring an explicit `!<plugin-name>` suffix.

### Issue Context
This affects both the default rhdh-local dynamic plugins config and the CI-only override created in the composite action.

### Fix Focus Areas
- configs/dynamic-plugins/dynamic-plugins.yaml[12-30]
- .github/actions/rhdh-local-compose-test/action.yaml[221-232]

### What to change
- For each `oci://...rhdh-plugin-export-overlays/...` ref, confirm whether the OCI image contains exactly one dynamic package.
- If it contains multiple, update the config to use:
 - `oci://<image>:<tag>!<plugin-path>`
 where `<plugin-path>` matches the desired package from the image’s `io.backstage.dynamic-packages` annotation.
- Apply the same fix to the CI override entry so `/api/extensions/loaded-plugins` validation doesn’t fail early.

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

---

View more (3)

4. Lightspeed docs now incorrect 🐞 Bug ⚙ Maintainability

Description

configs/dynamic-plugins/dynamic-plugins.yaml now disables both Lightspeed plugins by default, but
the Lightspeed docs still instruct users to disable them via an override file and describe the
previous default behavior. This creates a behavior/documentation mismatch that can confuse users and
hides Lightspeed UI by default.

Code

configs/dynamic-plugins/dynamic-plugins.yaml[R45-48]

+  # TODO: re-enable this once the catalog index is stabilized
  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed:{{inherit}}'
-    disabled: false
+    disabled: true

Relevance

●●● Strong

Docs drift fixes are commonly accepted; team frequently updates docs to match new default behaviors.

PR-#147
PR-#239

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The default dynamic plugins config now explicitly disables Lightspeed, while the docs still describe
disabling it through an override file by adding the same entries with disabled: true.

configs/dynamic-plugins/dynamic-plugins.yaml[40-52]
docs/lightspeed/working-with-lightspeed.md[255-292]

Agent prompt

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

## Issue description
Lightspeed plugins are now disabled by default in `configs/dynamic-plugins/dynamic-plugins.yaml`, but the documentation still describes disabling them via an override and implies they are enabled (but dormant) by default.

## Issue Context
This PR changes default behavior; docs should either be updated to reflect the new default (and document how to re-enable), or the config should be reverted to keep the documented defaults.

## Fix Focus Areas
- configs/dynamic-plugins/dynamic-plugins.yaml[44-52]
- docs/lightspeed/working-with-lightspeed.md[255-292]

## Suggested fix
Either:
1) Update the Lightspeed docs to state Lightspeed is disabled by default (and show how to enable it), or
2) Revert the default plugin entries back to `disabled: false` if the intent is to keep Lightspeed enabled by default (even if unconfigured).

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

---

5. Quay key drift 🔗 Cross-repo conflict ≡ Correctness

Description

This PR changes the Quay configuration key from quay.uiUrl to quay.apiUrl in rhdh-local’s
default app-config. In rhdh-plugins, Quay configuration examples still use quay.uiUrl, so the Quay
plugin may not find its expected config and could fail to generate correct UI links.

Code

configs/app-config/app-config.yaml[R272-274]

quay:
  # The UI url for Quay, used to generate the link to Quay
-  uiUrl: "https://quay.io"
+  apiUrl: "https://quay.io"

Relevance

●● Moderate

Cross-repo config contract change is risky; no close precedent found for Quay key rename
expectations.

PR-#212

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the Quay config key to apiUrl, while rhdh-plugins’ published example configs
continue to use uiUrl, indicating a contract mismatch across repos.

configs/app-config/app-config.yaml[257-275]
External repo: redhat-developer/rhdh-plugins, workspaces/extensions/examples/extra/community/quay.yaml [61-78]
External repo: redhat-developer/rhdh-plugins, workspaces/orchestrator/app-config.yaml [61-77]

Agent prompt

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

## Issue description
`configs/app-config/app-config.yaml` changed the Quay plugin config from `quay.uiUrl` to `quay.apiUrl`. Cross-repo examples in `rhdh-plugins` still document/configure Quay using `quay.uiUrl`, so the plugin may ignore `apiUrl` and behave incorrectly.

## Issue Context
- `rhdh-local` provides default runtime configuration consumed by RHDH + dynamic plugins.
- `rhdh-plugins` (Extensions examples + Orchestrator workspace config) still uses `quay.uiUrl`, indicating the expected config contract.

## Fix Focus Areas
- configs/app-config/app-config.yaml[272-275]

## Suggested change
- Prefer reverting to `quay.uiUrl`.
- If you intended to support a newer Quay plugin that expects `apiUrl`, consider setting **both** keys during a transition:
 - `uiUrl: https://quay.io`
 - `apiUrl: https://quay.io`
 so older/newer plugin versions remain compatible.

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

---

6. Orchestrator CI test removed 🐞 Bug ☼ Reliability

Description

The CI workflow no longer runs the orchestrator compose configuration, so regressions in
orchestrator/compose.yaml and orchestrator-specific override logic can land without any automated
coverage. The composite action still contains orchestrator-specific behavior, making this a real
ongoing blind spot until the test is restored.

Code

.github/workflows/test.yml[R49-52]

+# TODO: re-enable this test once we can use the right references.
+# Tracked in https://redhat.atlassian.net/browse/RHDHBUGS-3559
+#          - name: "orchestrator-workflow"
+#            cliArgs: "-f compose.yaml -f orchestrator/compose.yaml"

Relevance

●● Moderate

Coverage gaps in CI are usually addressed, but this is blocked by an open TODO/bug reference.

PR-#177
PR-#180

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow matrix entry for orchestrator is commented out, while the composite action still
contains an orchestrator-specific override step, demonstrating orchestrator behavior remains but is
no longer tested.

.github/workflows/test.yml[43-55]
.github/actions/rhdh-local-compose-test/action.yaml[251-262]

Agent prompt

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

## Issue description
The `orchestrator-workflow` compose matrix entry is commented out, removing CI coverage for orchestrator-specific compose/config behavior.

## Issue Context
The composite action still has an orchestrator-specific step (`Add orchestrator plugins to dynamic-plugins override`), so disabling the orchestrator matrix entry leaves real logic untested.

## Fix Focus Areas
- .github/workflows/test.yml[49-52]

## Suggested fix
Re-enable the `orchestrator-workflow` matrix entry (or add a dedicated orchestrator job). If the current references are temporarily invalid, consider running it as non-blocking (e.g., separate job with `continue-on-error: true`) until the correct references are available, then restore full enforcement.

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

---

7. Misleading Quay config comment 🐞 Bug ⚙ Maintainability

Description

configs/app-config/app-config.yaml changed the Quay setting key from uiUrl to apiUrl but kept
a comment saying it is the UI URL used to generate links. This is internally inconsistent and can
cause future misconfiguration because the comment no longer matches the configured key.

Code

configs/app-config/app-config.yaml[R272-274]

quay:
  # The UI url for Quay, used to generate the link to Quay
-  uiUrl: "https://quay.io"
+  apiUrl: "https://quay.io"

Relevance

●●● Strong

Trivial comment/config consistency fix; similar comment cleanups in app-config were accepted before.

PR-#53
PR-#77

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The file shows the Quay block comment describing a UI URL while the configured key is apiUrl,
demonstrating a direct comment/config inconsistency introduced by this change.

configs/app-config/app-config.yaml[257-275]

Agent prompt

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

## Issue description
The Quay config comment states the value is the UI URL, but the configured key is now `apiUrl` (previously `uiUrl`). This mismatch is misleading.

## Issue Context
Even if `apiUrl` is the intended key, the comment should reflect that; if `uiUrl` is still required somewhere, the key should be restored.

## Fix Focus Areas
- configs/app-config/app-config.yaml[272-275]

## Suggested fix
Update the comment to match the key (`apiUrl`) and ensure the value is the intended API base, OR revert the key back to `uiUrl` if that is what consumers expect.

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

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit 1c271d4 ⚖️ Balanced

Results up to commit 1c271d4 ⚖️ Balanced

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

1. Lightspeed docs now incorrect 🐞 Bug ⚙ Maintainability

Description

configs/dynamic-plugins/dynamic-plugins.yaml now disables both Lightspeed plugins by default, but
the Lightspeed docs still instruct users to disable them via an override file and describe the
previous default behavior. This creates a behavior/documentation mismatch that can confuse users and
hides Lightspeed UI by default.

Code

configs/dynamic-plugins/dynamic-plugins.yaml[R45-48]

+  # TODO: re-enable this once the catalog index is stabilized
  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed:{{inherit}}'
-    disabled: false
+    disabled: true

Relevance

●●● Strong

Docs drift fixes are commonly accepted; team frequently updates docs to match new default behaviors.

PR-#147
PR-#239

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The default dynamic plugins config now explicitly disables Lightspeed, while the docs still describe
disabling it through an override file by adding the same entries with disabled: true.

configs/dynamic-plugins/dynamic-plugins.yaml[40-52]
docs/lightspeed/working-with-lightspeed.md[255-292]

Agent prompt

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

## Issue description
Lightspeed plugins are now disabled by default in `configs/dynamic-plugins/dynamic-plugins.yaml`, but the documentation still describes disabling them via an override and implies they are enabled (but dormant) by default.

## Issue Context
This PR changes default behavior; docs should either be updated to reflect the new default (and document how to re-enable), or the config should be reverted to keep the documented defaults.

## Fix Focus Areas
- configs/dynamic-plugins/dynamic-plugins.yaml[44-52]
- docs/lightspeed/working-with-lightspeed.md[255-292]

## Suggested fix
Either:
1) Update the Lightspeed docs to state Lightspeed is disabled by default (and show how to enable it), or
2) Revert the default plugin entries back to `disabled: false` if the intent is to keep Lightspeed enabled by default (even if unconfigured).

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

---

2. Quay key drift 🔗 Cross-repo conflict ≡ Correctness

Description

This PR changes the Quay configuration key from quay.uiUrl to quay.apiUrl in rhdh-local’s
default app-config. In rhdh-plugins, Quay configuration examples still use quay.uiUrl, so the Quay
plugin may not find its expected config and could fail to generate correct UI links.

Code

configs/app-config/app-config.yaml[R272-274]

quay:
  # The UI url for Quay, used to generate the link to Quay
-  uiUrl: "https://quay.io"
+  apiUrl: "https://quay.io"

Relevance

●● Moderate

Cross-repo config contract change is risky; no close precedent found for Quay key rename
expectations.

PR-#212

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the Quay config key to apiUrl, while rhdh-plugins’ published example configs
continue to use uiUrl, indicating a contract mismatch across repos.

configs/app-config/app-config.yaml[257-275]
External repo: redhat-developer/rhdh-plugins, workspaces/extensions/examples/extra/community/quay.yaml [61-78]
External repo: redhat-developer/rhdh-plugins, workspaces/orchestrator/app-config.yaml [61-77]

Agent prompt

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

## Issue description
`configs/app-config/app-config.yaml` changed the Quay plugin config from `quay.uiUrl` to `quay.apiUrl`. Cross-repo examples in `rhdh-plugins` still document/configure Quay using `quay.uiUrl`, so the plugin may ignore `apiUrl` and behave incorrectly.

## Issue Context
- `rhdh-local` provides default runtime configuration consumed by RHDH + dynamic plugins.
- `rhdh-plugins` (Extensions examples + Orchestrator workspace config) still uses `quay.uiUrl`, indicating the expected config contract.

## Fix Focus Areas
- configs/app-config/app-config.yaml[272-275]

## Suggested change
- Prefer reverting to `quay.uiUrl`.
- If you intended to support a newer Quay plugin that expects `apiUrl`, consider setting **both** keys during a transition:
 - `uiUrl: https://quay.io`
 - `apiUrl: https://quay.io`
 so older/newer plugin versions remain compatible.

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

---

3. Orchestrator CI test removed 🐞 Bug ☼ Reliability

Description

The CI workflow no longer runs the orchestrator compose configuration, so regressions in
orchestrator/compose.yaml and orchestrator-specific override logic can land without any automated
coverage. The composite action still contains orchestrator-specific behavior, making this a real
ongoing blind spot until the test is restored.

Code

.github/workflows/test.yml[R49-52]

+# TODO: re-enable this test once we can use the right references.
+# Tracked in https://redhat.atlassian.net/browse/RHDHBUGS-3559
+#          - name: "orchestrator-workflow"
+#            cliArgs: "-f compose.yaml -f orchestrator/compose.yaml"

Relevance

●● Moderate

Coverage gaps in CI are usually addressed, but this is blocked by an open TODO/bug reference.

PR-#177
PR-#180

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow matrix entry for orchestrator is commented out, while the composite action still
contains an orchestrator-specific override step, demonstrating orchestrator behavior remains but is
no longer tested.

.github/workflows/test.yml[43-55]
.github/actions/rhdh-local-compose-test/action.yaml[251-262]

Agent prompt

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

## Issue description
The `orchestrator-workflow` compose matrix entry is commented out, removing CI coverage for orchestrator-specific compose/config behavior.

## Issue Context
The composite action still has an orchestrator-specific step (`Add orchestrator plugins to dynamic-plugins override`), so disabling the orchestrator matrix entry leaves real logic untested.

## Fix Focus Areas
- .github/workflows/test.yml[49-52]

## Suggested fix
Re-enable the `orchestrator-workflow` matrix entry (or add a dedicated orchestrator job). If the current references are temporarily invalid, consider running it as non-blocking (e.g., separate job with `continue-on-error: true`) until the correct references are available, then restore full enforcement.

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

---

4. Misleading Quay config comment 🐞 Bug ⚙ Maintainability

Description

configs/app-config/app-config.yaml changed the Quay setting key from uiUrl to apiUrl but kept
a comment saying it is the UI URL used to generate links. This is internally inconsistent and can
cause future misconfiguration because the comment no longer matches the configured key.

Code

configs/app-config/app-config.yaml[R272-274]

quay:
  # The UI url for Quay, used to generate the link to Quay
-  uiUrl: "https://quay.io"
+  apiUrl: "https://quay.io"

Relevance

●●● Strong

Trivial comment/config consistency fix; similar comment cleanups in app-config were accepted before.

PR-#53
PR-#77

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The file shows the Quay block comment describing a UI URL while the configured key is apiUrl,
demonstrating a direct comment/config inconsistency introduced by this change.

configs/app-config/app-config.yaml[257-275]

Agent prompt

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

## Issue description
The Quay config comment states the value is the UI URL, but the configured key is now `apiUrl` (previously `uiUrl`). This mismatch is misleading.

## Issue Context
Even if `apiUrl` is the intended key, the comment should reflect that; if `uiUrl` is still required somewhere, the key should be restored.

## Fix Focus Areas
- configs/app-config/app-config.yaml[272-275]

## Suggested fix
Update the comment to match the key (`apiUrl`) and ensure the value is the intended API base, OR revert the key back to `uiUrl` if that is what consumers expect.

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

---

[rhdh-qodo-merge]

PR Summary by Qodo

Align default dynamic plugin refs with next catalog index (and adjust CI matrix)

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Switch default dynamic plugin configuration from local dist paths to OCI image references.
• Add extensions-backend plugin to CI override to enable /api/extensions for plugin list validation.
• Temporarily disable orchestrator compose test in the CI matrix until references stabilize.

Diagram

graph TD
  A(["GitHub Actions CI"]) --> B[".github/workflows/test.yml"] --> C[".github/actions/.../action.yaml"] --> D["dynamic-plugins.override.yaml"] --> F(["RHDH compose runtime"]) --> H{{"OCI registries / index"}}
  E["configs/dynamic-plugins/dynamic-plugins.yaml"] --> F
  G["configs/app-config/app-config.yaml"] --> F

  subgraph Legend
    direction LR
    _ci(["CI job/step"]) ~~~ _file["Config file"] ~~~ _ext{{"External source"}}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Auto-sync default plugin config from `next` DPDY in CI

• ➕ Avoids manual drift between repo config and catalog index content
• ➕ Can fail fast when next changes by regenerating and diffing expected output
• ➖ Requires additional tooling (parser/generator) and a clear source-of-truth contract
• ➖ May introduce noisy churn if next is frequently updated

2. Prefer `{{inherit}}` tags everywhere (avoid pinned bs_* versions)

• ➕ Reduces maintenance burden when base Backstage/RHDH versions move
• ➕ Keeps config aligned with index tag semantics
• ➖ Not always possible if some plugins in next require explicit pinned tags
• ➖ Can make breakages harder to diagnose if inherit resolution changes

3. Keep orchestrator test enabled with a targeted matrix condition/override

• ➕ Maintains coverage for orchestrator compose configuration
• ➕ Limits regression risk from silently skipping a matrix leg
• ➖ May still be flaky/blocking until correct references are available
• ➖ Adds conditional complexity to the workflow and configs

Recommendation: The PR’s approach is reasonable as a short-term stabilization step: update default plugin refs to match what next actually provides, and inject only the minimum CI-only plugin needed to validate the plugin list. The main follow-up worth prioritizing is an automated sync/validation step against next (or a stronger {{inherit}} convention) so these reference drifts don’t keep recurring, and re-enable the orchestrator matrix leg once references are corrected (tracked by RHDHBUGS-3559).

Files changed (4) +24 / -22

Bug fix (1) +1 / -1

app-config.yamlFix Quay proxy configuration key (uiUrl -> apiUrl) +1/-1

Fix Quay proxy configuration key (uiUrl -> apiUrl)

• Replaces the Quay proxy configuration key from uiUrl to apiUrl. This aligns the config with expected proxy settings for Quay access.

configs/app-config/app-config.yaml

Other (3) +23 / -21

action.yamlInject extensions-backend plugin into CI override config +8/-0

Inject extensions-backend plugin into CI override config

• Updates the CI action that generates configs/dynamic-plugins/dynamic-plugins.override.yaml to include the extensions-backend plugin from an OCI reference. This enables the /api/extensions endpoint for CI validation while disabling actual extensions installation via pluginConfig.

.github/actions/rhdh-local-compose-test/action.yaml

test.ymlTemporarily disable orchestrator compose job in matrix +4/-2

Temporarily disable orchestrator compose job in matrix

• Comments out the orchestrator-workflow entry from the compose test matrix. Adds a TODO and tracking link to re-enable once correct references are available (RHDHBUGS-3559).

.github/workflows/test.yml

dynamic-plugins.yamlSwitch default dynamic plugins to OCI references and gate Lightspeed +11/-19

Switch default dynamic plugins to OCI references and gate Lightspeed

• Replaces local ./dynamic-plugins/dist plugin paths with OCI references for tech-radar, scaffolder GitHub backend module, and extensions plugins to match what’s available in the 'next' catalog index. Pins some references to specific bs_* versions, and temporarily disables Lightspeed frontend/backend plugins pending catalog index stabilization.

configs/dynamic-plugins/dynamic-plugins.yaml

[rm3l]

Merging to unblock the 2.1 milestone test day, but we'll need to optimize some of the plugin references here, for example by ideally relying on the work done in redhat-developer/rhdh-plugins#4110 (once available in the RHDH next image).

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 1c271d4