chore: replace disabled with enabled in DPY files

[hopehadfield]

Description

Replace disabled: true/false with enabled: true/false in dynamic plugin configs and docs.

• configs/dynamic-plugins/dynamic-plugins.yaml
• configs/dynamic-plugins/dynamic-plugins.override.example.yaml
• docs/lightspeed/working-with-lightspeed.md
• orchestrator/README.md

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

• Fixes RHIDP-14726

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

[rhdh-qodo-merge]

PR Summary by Qodo

Replace disabled with enabled in dynamic plugin configs and docs
⚙️ Configuration changes 📝 Documentation 🕐 10-20 Minutes

Description

• Rename dynamic plugin toggle key from disabled to enabled in YAML configs
• Update Lightspeed and Orchestrator docs to match the new enabled: true/false convention
• Keep example override snippets consistent with current dynamic plugin configuration semantics

Diagram

graph TD
  OP["Operator"] --> CFG["dynamic-plugins*.yaml"] --> LDR["Dynamic plugin loader"] --> PLG["Plugins active"]
  DOC["Docs (Lightspeed/Orchestrator)"] --> OP

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Dual-key compatibility (`enabled` + legacy `disabled`)

• ➕ Reduces breakage for existing user configs and downstream examples
• ➕ Allows gradual migration with clear precedence rules
• ➖ Requires parser/runtime support and additional tests
• ➖ Adds ambiguity if both keys are present without well-defined precedence

2. Migration guidance + validation

• ➕ Keeps runtime simple while helping users update safely
• ➕ Can catch misconfigurations early (schema validation / linting)
• ➖ Still requires users to manually migrate existing files
• ➖ Validation tooling may not exist or may add CI overhead

Recommendation: The PR’s approach (standardizing on enabled) is the right direction for clarity and consistency, especially in docs and shipped example configs. Ensure the underlying dynamic-plugin config consumer either already supports enabled or provides clear migration/compat messaging (and precedence rules if disabled remains accepted) to avoid surprising breakages.

Files changed (5) +29 / -29

Documentation (2) +7 / -7

working-with-lightspeed.mdAlign Lightspeed disable instructions with 'enabled: false' +3/-3

Align Lightspeed disable instructions with 'enabled: false'

• Updates the Lightspeed disablement instructions and YAML snippet to use 'enabled: false' instead of 'disabled: true'. This ensures documentation matches the updated dynamic plugin config format.

docs/lightspeed/working-with-lightspeed.md

README.mdUpdate Orchestrator README example to 'enabled: true' +4/-4

Update Orchestrator README example to 'enabled: true'

• Updates the README configuration snippet for Orchestrator-related plugins to use 'enabled: true'. Keeps documentation consistent with the dynamic plugin configuration key rename.

orchestrator/README.md

Other (3) +22 / -22

dynamic-plugins.override.example.yamlUpdate override example comments to use 'enabled' +10/-10

Update override example comments to use 'enabled'

• Replaces commented 'disabled: true/false' examples with the equivalent 'enabled: false/true' values. Keeps the sample override file aligned with the current dynamic plugin configuration convention.

configs/dynamic-plugins/dynamic-plugins.override.example.yaml

dynamic-plugins.yamlSwitch plugin toggles from 'disabled' to 'enabled' +8/-8

Switch plugin toggles from 'disabled' to 'enabled'

• Renames the per-plugin toggle key to 'enabled' throughout the primary dynamic plugin config. Preserves the prior behavior by inverting values where appropriate (e.g., previously 'disabled: true' becomes 'enabled: false').

configs/dynamic-plugins/dynamic-plugins.yaml

dynamic-plugins.yamlRename Orchestrator plugin toggles to 'enabled' +4/-4

Rename Orchestrator plugin toggles to 'enabled'

• Switches Orchestrator dynamic plugin configuration entries from 'disabled: false' to 'enabled: true'. Maintains the same activation behavior with the new key name.

orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: RHIDP-14726

1. Orchestrator YAML uses disabled ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml still uses disabled: false while the
PR updates the Orchestrator README example and the primary dynamic-plugins config to the new
enabled: true/false key. This leaves two competing config formats in-repo and makes the README’s
“copy plugins from orchestrator/configs/…” instruction likely to produce an out-of-date override
snippet.

Code

orchestrator/README.md[R16-19]

  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-orchestrator:{{inherit}}'
-    disabled: false
+    enabled: true
  - package: 'oci://registry.access.redhat.com/rhdh/red-hat-developer-hub-backstage-plugin-orchestrator-backend:{{inherit}}'
-    disabled: false
+    enabled: true

Relevance

⭐⭐⭐ High

Team historically enforces README/config consistency; accepted fixes updating referenced
orchestrator plugin snippets and config paths (PRs #183, #34).

PR-#183
PR-#34
PR-#164

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes the Orchestrator README example plugin entries to enabled: true and tells users to
copy the plugin list from orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml, but that
referenced file still contains disabled: false entries. The main default dynamic plugins config
also now uses enabled: ..., reinforcing that the orchestrator template is the odd one out.

orchestrator/README.md[6-32]
orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml[5-21]
configs/dynamic-plugins/dynamic-plugins.yaml[7-40]

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 repo is being migrated from `disabled: true/false` to `enabled: true/false` for dynamic plugin entries. After this PR, `orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml` still uses `disabled: false`, but `orchestrator/README.md` instructs users to copy plugin entries from that file and shows examples using `enabled: true`.

### Issue Context
This creates an inconsistent and confusing Orchestrator onboarding path: users following the README to copy the plugin list will copy the older `disabled:` key instead of the new `enabled:` key used elsewhere in the repo.

### Fix Focus Areas
- orchestrator/configs/dynamic-plugins/dynamic-plugins.yaml[5-21]

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

---

[rhdh-qodo-merge]

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

[rm3l]

Looks like there are still a few occurrences to update here: https://github.com/hopehadfield/rhdh-local/blob/replace-disabled/.github/actions/rhdh-local-compose-test/action.yaml#L225-L228

[rm3l]

/hold

[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

[hopehadfield]

Just updated, thanks for the review @rm3l!