chore(lightspeed): use inherit for pluginConfig

[Jdubrick]

Description

• Removes pluginConfig and instead relies on inherit as the pluginConfig has been updated in the DPDY https://gitlab.cee.redhat.com/rhidp/rhdh-plugin-catalog/-/blob/rhdh-1-rhel-9/catalog-index/dynamic-plugins.default.yaml#L907-949

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

• Fixes #issue_number

PR acceptance criteria

• Tests
• Documentation

How to test changes / Special notes to the reviewer

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

Context used

✅ Compliance rules (platform): 18 rules

1. Lightspeed docs outdated 🐞 Bug ⚙ Maintainability

Description

The Lightspeed documentation claims the chat UI elements are configured via the plugin’s
pluginConfig, but the Lightspeed flavour overlay in this repo no longer contains any
pluginConfig for the plugin. This mismatch will mislead users trying to customize or troubleshoot
Lightspeed enablement.

Code

config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml[R8-13]

      # Lightspeed Plugins
      - package: oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed:{{inherit}}
        disabled: false
-        pluginConfig:
-          dynamicPlugins:
-            frontend:
-              red-hat-developer-hub.backstage-plugin-lightspeed:
-                translationResources:
-                  - importName: lightspeedTranslations
-                    module: Alpha
-                    ref: lightspeedTranslationRef
-                dynamicRoutes:
-                  - path: /lightspeed
-                    importName: LightspeedPage
-                mountPoints:
-                  - mountPoint: application/listener
-                    importName: LightspeedFAB
-                  - mountPoint: application/provider
-                    importName: LightspeedDrawerProvider
-                  - mountPoint: application/internal/drawer-state
-                    importName: LightspeedDrawerStateExposer
-                    config:
-                      id: lightspeed
-                  - mountPoint: application/internal/drawer-content
-                    importName: LightspeedChatContainer
-                    config:
-                      id: lightspeed
-                      priority: 100
+
      - package: oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed-backend:{{inherit}}
        disabled: false

Relevance

⭐⭐⭐ High

Docs fixes for Lightspeed are frequently accepted; reviewers updated/clarified docs/lightspeed.md in
PR #2641 and #2719.

PR-#2641
PR-#2719

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The docs explicitly describe UI behavior as configured through pluginConfig, while the Lightspeed
flavour’s dynamic-plugins overlay now only declares the packages and disabled flags (no
pluginConfig).

docs/lightspeed.md[94-102]
config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml[6-13]

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 docs reference UI configuration via `pluginConfig`, but the Lightspeed flavour dynamic-plugins overlay no longer includes a `pluginConfig` block.

## Issue Context
If `pluginConfig` is now expected to come from the catalog index’s `dynamic-plugins.default.yaml`, docs should say so and explain how to override it.

## Fix Focus Areas
- docs/lightspeed.md[94-102]

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

---

2. Lightspeed pluginConfig removed 🐞 Bug ≡ Correctness

Description

The Lightspeed flavour no longer provides any pluginConfig for the frontend Lightspeed plugin, so
its UI integration (routes/mount points/translations) is no longer defined by the operator repo and
instead relies on external catalog-index defaults. If a deployment uses a catalog index image that
doesn’t include the Lightspeed pluginConfig (or includes an incompatible one), the Lightspeed UI
elements may not be registered correctly.

Code

config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml[R8-13]

      # Lightspeed Plugins
      - package: oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed:{{inherit}}
        disabled: false
-        pluginConfig:
-          dynamicPlugins:
-            frontend:
-              red-hat-developer-hub.backstage-plugin-lightspeed:
-                translationResources:
-                  - importName: lightspeedTranslations
-                    module: Alpha
-                    ref: lightspeedTranslationRef
-                dynamicRoutes:
-                  - path: /lightspeed
-                    importName: LightspeedPage
-                mountPoints:
-                  - mountPoint: application/listener
-                    importName: LightspeedFAB
-                  - mountPoint: application/provider
-                    importName: LightspeedDrawerProvider
-                  - mountPoint: application/internal/drawer-state
-                    importName: LightspeedDrawerStateExposer
-                    config:
-                      id: lightspeed
-                  - mountPoint: application/internal/drawer-content
-                    importName: LightspeedChatContainer
-                    config:
-                      id: lightspeed
-                      priority: 100
+
      - package: oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-lightspeed-backend:{{inherit}}
        disabled: false

Relevance

⭐ Low

Team previously moved dynamic plugin config to rely on {{inherit}}/catalog defaults (accepted in PR
#2231; merged Lightspeed inherit PR #2756).

PR-#2231
PR-#2756

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Lightspeed flavour overlay now lists only the plugin packages and disabled flags, with no
pluginConfig content; the base profile relies on dynamic-plugins.default.yaml from the catalog
index for defaults; and the Lightspeed docs still describe the UI elements as being driven by
pluginConfig. Together this shows the repo no longer provides the Lightspeed UI wiring itself and
that behavior now depends on external defaults.

config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml[1-13]
config/profile/rhdh/default-config/dynamic-plugins.yaml[21-30]
docs/dynamic-plugins.md[46-52]
docs/lightspeed.md[94-102]

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 Lightspeed flavour dynamic plugins overlay no longer ships the Lightspeed frontend `pluginConfig` (dynamicRoutes/mountPoints/translation resources). This makes the flavour’s behavior depend on whatever `dynamic-plugins.default.yaml` is provided by the catalog index image at runtime.

## Issue Context
- The base RHDH profile dynamic plugins ConfigMap only includes `dynamic-plugins.default.yaml`; it does not define any plugin entries or pluginConfig itself.
- The operator supports loading default plugin configuration from a catalog index OCI image, and that image is configurable/overridable.

## Fix Focus Areas
- Re-add the Lightspeed frontend `pluginConfig` block to the Lightspeed flavour overlay (to make the flavour self-contained), OR
- Add an explicit comment + documentation stating that Lightspeed requires the catalog index to provide the Lightspeed `pluginConfig`, and add a CI/validation step if available to ensure the selected catalog index contains that config.

### Files/lines to change
- config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml[7-13]
- bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml[320-327]
- dist/rhdh/install.yaml[3342-3349]

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

---

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
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

[Jdubrick]

/cc @rm3l

Not sure if there is a cherry-pick option or if I need a separate PR to release branch?

[rhdh-qodo-merge]

Review Summary by Qodo

Remove explicit pluginConfig and use inherit for Lightspeed plugin

✨ Enhancement

Walkthroughs

Description

• Remove explicit pluginConfig from Lightspeed plugin configuration
• Rely on inherit mechanism for plugin configuration
• Simplify dynamic plugin setup across multiple manifests
• Update timestamps in operator ClusterServiceVersion files

Diagram

flowchart LR
  A["Lightspeed Plugin Config"] -->|Remove pluginConfig| B["Use inherit mechanism"]
  B -->|Simplify| C["Dynamic Plugins YAML"]
  C -->|Apply to| D["Multiple Manifests"]

Loading

File Changes

1. bundle/backstage.io/manifests/backstage-operator.clusterserviceversion.yaml ⚙️ Configuration changes +1/-1

Update operator timestamp

• Update createdAt timestamp from 2026-05-04 to 2026-05-14

bundle/backstage.io/manifests/backstage-operator.clusterserviceversion.yaml

---

2. bundle/rhdh/manifests/backstage-operator.clusterserviceversion.yaml ⚙️ Configuration changes +1/-1

Update RHDH operator timestamp

• Update createdAt timestamp from 2026-05-04 to 2026-05-14

bundle/rhdh/manifests/backstage-operator.clusterserviceversion.yaml

---

3. bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml ✨ Enhancement +1/-25

Remove explicit Lightspeed pluginConfig configuration

• Remove explicit pluginConfig section from Lightspeed frontend plugin
• Remove 24 lines of hardcoded plugin configuration (translations, routes, mount points)
• Rely on inherit mechanism for configuration instead

bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml

---

View more (2)

4. config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml ✨ Enhancement +1/-25

Remove explicit Lightspeed pluginConfig configuration

• Remove explicit pluginConfig section from Lightspeed frontend plugin
• Remove 24 lines of hardcoded plugin configuration (translations, routes, mount points)
• Rely on inherit mechanism for configuration instead

config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml

---

5. dist/rhdh/install.yaml ✨ Enhancement +1/-25

Remove explicit Lightspeed pluginConfig configuration

• Remove explicit pluginConfig section from Lightspeed frontend plugin
• Remove 24 lines of hardcoded plugin configuration (translations, routes, mount points)
• Rely on inherit mechanism for configuration instead

dist/rhdh/install.yaml

---

[rm3l]

Not sure if there is a cherry-pick option or if I need a separate PR to release branch?

/cherry-pick release-1.10

Since main and release-1.10 are quite identical at this time, the automated cherry-pick should work without conflicts, I think. Let's see.

[openshift-cherrypick-robot]

@rm3l: once the present PR merges, I will cherry-pick it on top of release-1.10 in a new PR and assign it to you.

Details

In response to this:

Not sure if there is a cherry-pick option or if I need a separate PR to release branch?

/cherry-pick release-1.10

Since main and release-1.10 are quite identical at this time, the automated cherry-pick should work without conflicts, I think. Let's see.

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.

[github-actions]

PR images are available:

1. https://quay.io/rhdh-community/operator:0.10.0-pr-2848-a666114
2. https://quay.io/rhdh-community/operator-bundle:0.10.0-pr-2848-a666114
3. https://quay.io/rhdh-community/operator-catalog:0.10.0-pr-2848-a666114

[openshift-cherrypick-robot]

@rm3l: #2848 failed to apply on top of branch "release-1.10":

Applying: chore(lightspeed): use inherit for pluginConfig
Using index info to reconstruct a base tree...
M	bundle/backstage.io/manifests/backstage-operator.clusterserviceversion.yaml
M	bundle/rhdh/manifests/backstage-operator.clusterserviceversion.yaml
M	dist/rhdh/install.yaml
Falling back to patching base and 3-way merge...
Auto-merging dist/rhdh/install.yaml
Auto-merging bundle/rhdh/manifests/backstage-operator.clusterserviceversion.yaml
CONFLICT (content): Merge conflict in bundle/rhdh/manifests/backstage-operator.clusterserviceversion.yaml
Auto-merging bundle/backstage.io/manifests/backstage-operator.clusterserviceversion.yaml
CONFLICT (content): Merge conflict in bundle/backstage.io/manifests/backstage-operator.clusterserviceversion.yaml
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 set advice.mergeConflict false"
Patch failed at 0001 chore(lightspeed): use inherit for pluginConfig

Details

In response to this:

Not sure if there is a cherry-pick option or if I need a separate PR to release branch?

/cherry-pick release-1.10

Since main and release-1.10 are quite identical at this time, the automated cherry-pick should work without conflicts, I think. Let's see.

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.