chore(lightspeed): use inherit for pluginConfig

[Jdubrick]

Description of the change

• Uses inherit to get the pluginConfig for Lightspeed. Similar change opened for Operator: chore(lightspeed): use inherit for pluginConfig rhdh-operator#2848

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

N/A

How to test changes / Special notes to the reviewer

Checklist

• For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
• For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Run pre-commit run --all-files to run the hooks and then push any resulting changes. The pre-commit Workflow will enforce this and warn you if needed.
• JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
• Tests pass using the Chart Testing tool and the ct lint command.
• If you updated the orchestrator-infra chart, make sure the versions of the Knative CRDs are aligned with the versions of the CRDs installed by the OpenShift Serverless operators declared in the values.yaml file. See Installing Knative Eventing and Knative Serving CRDs for more details.

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

1. Lightspeed UI config removed 🐞 Bug ≡ Correctness

Description

The chart no longer provides the default Lightspeed pluginConfig fragment, so the rendered
dynamic-plugins.yaml will no longer include the /lightspeed route, mountPoints, and
translationResources that were previously injected via global.lightspeed.plugins[0].pluginConfig.
Because the dynamic-plugins ConfigMap template only concatenates plugin entries, this configuration
is not reintroduced elsewhere in the chart.

Code

charts/backstage/values.yaml[R56-61]

    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

Similar change (“remove Lightspeed pluginConfig when using {{inherit}}”) was definitely rejected in
PR #377.

PR-#377

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

global.lightspeed.plugins now defaults to package/disabled only, and the dynamic-plugins.yaml
ConfigMap is built by appending global.lightspeed.plugins entries directly into
global.dynamic.plugins without adding any missing pluginConfig. Therefore, removing
pluginConfig from the Lightspeed plugin entry removes that app-config fragment from the rendered
output.

charts/backstage/values.yaml[50-62]
charts/backstage/templates/dynamic-plugins-configmap.yaml[6-29]
charts/backstage/values.schema.json[222-231]

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 PR removes the default `pluginConfig` for the Lightspeed frontend plugin from `global.lightspeed.plugins`. The dynamic plugin installer ConfigMap is generated by concatenating plugin entries and rendering them as-is, so the chart will stop emitting the dynamic plugin app-config fragment that previously registered the Lightspeed route and mount points.

## Issue Context
Previously, the Lightspeed plugin entry carried a `pluginConfig.dynamicPlugins.frontend...` fragment that declared `dynamicRoutes` (including `/lightspeed`), `mountPoints` (FAB/drawer integrations), and `translationResources`. After this change, `global.lightspeed.plugins` defaults are only `{package, disabled}`.

## Fix Focus Areas
- charts/backstage/values.yaml[52-61]
- charts/backstage/values.schema.json[222-231]
- charts/backstage/templates/dynamic-plugins-configmap.yaml[6-29]
- charts/backstage/README.md[188-192]

## What to change
1. Re-introduce the removed `pluginConfig` fragment for the Lightspeed frontend plugin under `global.lightspeed.plugins[0]` (or move it to another chart-managed config location that is guaranteed to be rendered into `dynamic-plugins.yaml`).
2. Keep `values.schema.json` defaults and README examples in sync with the chosen approach.
3. If the intention is to have the plugin package supply this config, explicitly relocate the config into a chart-managed place (or document/validate that the rendered `dynamic-plugins.yaml` still includes the needed fragment) so that the chart output remains functionally equivalent.

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

---

[Jdubrick]

/cc @rm3l

Same comment as Operator, not sure if there is a cherry-pick command or if I just need to open another PR to release branch?

[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

[rhdh-qodo-merge]

Review Summary by Qodo

Remove inline pluginConfig from Lightspeed plugin

✨ Enhancement

Walkthroughs

Description

• Remove inline pluginConfig from Lightspeed frontend plugin
• Use inherit mechanism for plugin configuration
• Simplify plugin definitions by delegating config to package
• Update schema and documentation to reflect changes

Diagram

flowchart LR
  A["Lightspeed Frontend Plugin<br/>with inline pluginConfig"] -->|Remove pluginConfig| B["Lightspeed Frontend Plugin<br/>with inherit mechanism"]
  B -->|Simplified config| C["Backend Plugin<br/>unchanged"]

Loading

File Changes

1. charts/backstage/values.yaml ⚙️ Configuration changes +1/-25

Remove inline pluginConfig from values

• Removed inline pluginConfig section from Lightspeed frontend plugin definition
• Removed 26 lines of nested dynamic plugin configuration (routes, mount points, translations)
• Kept package reference and disabled flag intact
• Configuration now inherited from plugin package

charts/backstage/values.yaml

---

2. charts/backstage/values.schema.json ⚙️ Configuration changes +2/-94

Remove pluginConfig from JSON schema

• Removed pluginConfig object from frontend plugin schema definition (appears twice in schema)
• Removed 46 lines of nested schema definitions for dynamic routes, mount points, and translations
• Simplified plugin schema to only include package and disabled fields
• Backend plugin schema remains unchanged

charts/backstage/values.schema.json

---

3. charts/backstage/README.md 📝 Documentation +1/-1

Update README plugin documentation

• Updated default value documentation for global.lightspeed.plugins
• Removed inline pluginConfig from example configuration
• Simplified plugin list to show only package and disabled fields
• Reduced documentation line length by removing nested configuration details

charts/backstage/README.md

---

[rm3l]

/cc @rm3l

Same comment as Operator, not sure if there is a cherry-pick command or if I just need to open another PR to release branch?

Yeah, you may not be able to use the cherry-pick release-1.10 slash comment, as the automated cherry-pick will likely fail due to conflicts with the chart versions. So you'll likely end up creating the cherry-pick PR manually against the release branch.

To also avoid conflicting Git tags between release-1.10 and main in the future, I'll be merging #395 to bump all the minor versions. So I'd say the easiest would be that your current PR (bumping the chart from 5.12.0 to 5.12.1) targets release-1.10 instead. And then create another one against main and bumping the chart version to 5.13.1 (once #395 is merged). Does that make sense?

[Jdubrick]

/cc @rm3l
Same comment as Operator, not sure if there is a cherry-pick command or if I just need to open another PR to release branch?

Yeah, you may not be able to use the cherry-pick release-1.10 slash comment, as the automated cherry-pick will likely fail due to conflicts with the chart versions. So you'll likely end up creating the cherry-pick PR manually against the release branch.

To also avoid conflicting Git tags between release-1.10 and main in the future, I'll be merging #395 to bump all the minor versions. So I'd say the easiest would be that your current PR (bumping the chart from 5.12.0 to 5.12.1) targets release-1.10 instead. And then create another one against main and bumping the chart version to 5.13.1 (once #395 is merged). Does that make sense?

@rm3l yeah that makes sense, I just updated the target to release-1.10