chore: replace disabled with enabled in DP configs by hopehadfield · Pull Request #3098 · redhat-developer/rhdh-operator

hopehadfield · 2026-06-25T19:43:53Z

Description

Replace disabled: true/false with enabled: true/false across all YAML configs, examples, and test data.

YAML configs: flavour defaults, examples, CR samples, bundle manifests, dist/rhdh/install.yaml, integration and model test data
pkg/model/dynamic-plugins.go: added Enabled *bool field to DynaPlugin, added IsDisabled() resolver (Enabled takes precedence over Disabled), merge copies both fields
Tests updated to use IsDisabled() assertions

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

Fixes RHIDP-14726

PR acceptance criteria

Tests
Documentation

How to test changes / Special notes to the reviewer

Building Container Images for Testing

Need to test container images from this PR?

For Maintainers: To trigger a test image build, review the code and comment /build-images.
This always builds the HEAD of the PR branch.

For Contributors: Ask a maintainer to run /build-images.

Images will be built and pushed to Quay with links posted in comments.

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

rhdh-qodo-merge · 2026-06-25T19:46:02Z

PR Summary by Qodo

Replace dynamic-plugins disabled with enabled across configs (with compatibility)

⚙️ Configuration changes ✨ Enhancement 📝 Documentation 🧪 Tests 🕐 40+ Minutes

AI Description

• Standardize dynamic plugin toggles by switching YAML from disabled to enabled.
• Add Enabled support in the dynamic plugin model with precedence over legacy Disabled.
• Update docs, examples, and tests to validate behavior via the new resolver.

Diagram

graph TD
  A["YAML configs"] --> B["YAML decode"] --> C["DynaPlugin"] --> D["IsDisabled()"] --> E["Dependencies()"] --> F["Runtime plugin set"]
  A --> G["MergePluginsData"] --> C

High-Level Assessment

The following are alternative approaches to this PR:

1. Custom YAML unmarshal + single canonical field

➕ Avoids carrying two persisted fields long-term
➕ Could support richer deprecation warnings when disabled is encountered
➖ More complex implementation and test surface
➖ Harder to reason about than a simple precedence resolver

2. One-time migration only (remove legacy support)

➕ Simpler model (only enabled) and less conditional logic
➕ Forces consistency quickly
➖ Breaking change for existing user configs/overlays
➖ Increases upgrade friction and support burden

Recommendation: Current approach (add Enabled *bool + IsDisabled() precedence + merge propagation) is the best tradeoff: it enables the config rename while preserving backward compatibility. Consider adding a future deprecation path (e.g., warning/logging when disabled is present) once the ecosystem migrates.

Files changed (24) +81 / -67

Enhancement (1) +15 / -1

dynamic-plugins.goModel: add 'Enabled *bool' and precedence resolver +15/-1

Model: add 'Enabled *bool' and precedence resolver

• Adds an optional 'Enabled' field to 'DynaPlugin' and introduces 'IsDisabled()' to resolve effective state, preferring 'Enabled' when set. Updates dependency filtering to use 'IsDisabled()' and updates merge logic to propagate 'Enabled' when provided.

pkg/model/dynamic-plugins.go

Tests (9) +16 / -16

raw-dynaplugins-with-deps.yamlIntegration test data: switch to 'enabled' for plugin toggles +2/-2

Integration test data: switch to 'enabled' for plugin toggles
• Updates integration test YAML to use 'enabled: true/false' for enabled/disabled plugin entries while keeping dependency structure unchanged.
integration_tests/testdata/raw-dynaplugins-with-deps.yaml

default-config_test.goTests: assert plugin state via 'IsDisabled()' +1/-1

Tests: assert plugin state via 'IsDisabled()'
• Updates merge-related assertions to use the new 'IsDisabled()' resolver rather than directly reading the legacy 'Disabled' field.
pkg/model/default-config_test.go

dynamic-plugins_test.goModel tests: switch state checks to 'IsDisabled()' +5/-5

Model tests: switch state checks to 'IsDisabled()'
• Replaces direct 'Disabled' field assertions with 'IsDisabled()' checks to validate the new precedence behavior. Also corrects an assertion message around expected marshalled content.
pkg/model/dynamic-plugins_test.go

dynamic-plugins-base.yamlModel testdata: base config uses 'enabled' +2/-2

Model testdata: base config uses 'enabled'
• Updates base dynamic plugin test data to use 'enabled: true/false' instead of 'disabled'.
pkg/model/testdata/dynamic-plugins-base.yaml

dynamic-plugins-overlay.yamlModel testdata: overlay config uses 'enabled' +2/-2

Model testdata: overlay config uses 'enabled'
• Updates overlay dynamic plugin test data to use 'enabled: true' for plugin entries.
pkg/model/testdata/dynamic-plugins-overlay.yaml

dynamic-plugins.yamlFlavour testdata: use 'enabled' for flavor3 +1/-1

Flavour testdata: use 'enabled' for flavor3
• Replaces 'disabled: false' with 'enabled: true' in flavour test config.
pkg/model/testdata/testflavours-nobase/default-config/flavours/flavor3/dynamic-plugins.yaml

dynamic-plugins.yamlFlavour testdata: use 'enabled' for base flavour config +1/-1

Flavour testdata: use 'enabled' for base flavour config
• Replaces 'disabled: false' with 'enabled: true' in default-config test data.
pkg/model/testdata/testflavours/default-config/dynamic-plugins.yaml

dynamic-plugins.yamlFlavour testdata: use 'enabled' for flavor1 +1/-1

Flavour testdata: use 'enabled' for flavor1
• Replaces 'disabled: false' with 'enabled: true' in flavour test config.
pkg/model/testdata/testflavours/default-config/flavours/flavor1/dynamic-plugins.yaml

dynamic-plugins.yamlFlavour testdata: use 'enabled' for flavor2 +1/-1

Flavour testdata: use 'enabled' for flavor2
• Replaces 'disabled: false' with 'enabled: true' in flavour test config.
pkg/model/testdata/testflavours/default-config/flavours/flavor2/dynamic-plugins.yaml

Documentation (5) +12 / -12

configuration.mdDocs: use 'enabled' in dynamic plugin example +1/-1

Docs: use 'enabled' in dynamic plugin example
• Updates configuration documentation examples to use 'enabled: true' instead of 'disabled: false'.
docs/configuration.md

dynamic-plugins.mdDocs: use 'enabled' in dynamic plugin schema examples +1/-1

Docs: use 'enabled' in dynamic plugin schema examples
• Replaces the documented plugin toggle field from 'disabled' to 'enabled' in examples.
docs/dynamic-plugins.md

lightspeed.mdDocs: Lightspeed example switches to 'enabled' +2/-2

Docs: Lightspeed example switches to 'enabled'
• Updates the Lightspeed dynamic plugin configuration snippet to use 'enabled: true'.
docs/lightspeed.md

orchestrator-cicd.mdDocs: Orchestrator CI/CD examples switch to 'enabled' +4/-4

Docs: Orchestrator CI/CD examples switch to 'enabled'
• Replaces 'disabled: false' with 'enabled: true' across the documented plugin list for ArgoCD/Tekton related configuration.
docs/orchestrator-cicd.md

orchestrator.mdDocs: Orchestrator plugin enablement uses 'enabled' +4/-4

Docs: Orchestrator plugin enablement uses 'enabled'
• Updates Orchestrator configuration instructions to use 'enabled: true' for plugin entries and modules.
docs/orchestrator.md

Other (9) +38 / -38

rhdh-flavour-lightspeed-config_v1_configmap.yamlSwitch Lightspeed flavour plugins to 'enabled: true' +2/-2

Switch Lightspeed flavour plugins to 'enabled: true'
• Updates the embedded dynamic-plugins YAML to use 'enabled: true' instead of 'disabled: false' for Lightspeed plugins.
bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml

rhdh-flavour-orchestrator-config_v1_configmap.yamlSwitch Orchestrator flavour plugins to 'enabled: true' +4/-4

Switch Orchestrator flavour plugins to 'enabled: true'
• Updates the embedded dynamic-plugins YAML to use 'enabled: true' instead of 'disabled: false' for Orchestrator plugins and related modules.
bundle/rhdh/manifests/rhdh-flavour-orchestrator-config_v1_configmap.yaml

dynamic-plugins.yamlUpdate default Lightspeed flavour dynamic-plugins to 'enabled' +2/-2

Update default Lightspeed flavour dynamic-plugins to 'enabled'
• Replaces 'disabled: false' with 'enabled: true' for Lightspeed plugin entries in the default profile config.
config/profile/rhdh/default-config/flavours/lightspeed/dynamic-plugins.yaml

dynamic-plugins.yamlUpdate default Orchestrator flavour dynamic-plugins to 'enabled' +4/-4

Update default Orchestrator flavour dynamic-plugins to 'enabled'
• Replaces 'disabled: false' with 'enabled: true' for Orchestrator plugin entries in the default profile config.
config/profile/rhdh/default-config/flavours/orchestrator/dynamic-plugins.yaml

install.yamlUpdate distributed install manifest dynamic-plugins to 'enabled' +6/-6

Update distributed install manifest dynamic-plugins to 'enabled'
• Replaces 'disabled' with 'enabled' for Lightspeed and Orchestrator dynamic plugin entries within the generated install manifest.
dist/rhdh/install.yaml

orchestrator-cicd.yamlExamples: Orchestrator CI/CD ConfigMap uses 'enabled' +11/-11

Examples: Orchestrator CI/CD ConfigMap uses 'enabled'
• Replaces 'disabled' with 'enabled' across orchestrator and CI/CD plugin entries in the example YAML.
examples/orchestrator-cicd.yaml

pvc-dp-cache.yamlExamples: invert 'disabled' values into 'enabled' booleans +5/-5

Examples: invert 'disabled' values into 'enabled' booleans
• Migrates example plugin toggles from 'disabled' to 'enabled', mapping 'disabled: true' to 'enabled: false' and preserving enabled entries as 'enabled: true'.
examples/pvc-dp-cache.yaml

rhdh-cr-with-app-configs.yamlExamples: CR with app configs uses 'enabled' toggles +3/-3

Examples: CR with app configs uses 'enabled' toggles
• Replaces 'disabled: false' with 'enabled: true' for referenced dynamic plugin entries in the example.
examples/rhdh-cr-with-app-configs.yaml

rhdh-cr.yamlExamples: CR dynamic plugins uses 'enabled' +1/-1

Examples: CR dynamic plugins uses 'enabled'
• Replaces 'disabled: false' with 'enabled: true' in the dynamic plugin entry example.
examples/rhdh-cr.yaml

codecov · 2026-06-25T19:48:58Z

Codecov Report

❌ Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 61.76%. Comparing base (c3ab615) to head (3c99a18).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/model/dynamic-plugins.go	90.90%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3098      +/-   ##
==========================================
+ Coverage   61.51%   61.76%   +0.25%     
==========================================
  Files          37       37              
  Lines        2162     2171       +9     
==========================================
+ Hits         1330     1341      +11     
+ Misses        691      690       -1     
+ Partials      141      140       -1

Flag	Coverage Δ
nightly	`?`
unittests	`61.76% <90.90%> (+0.25%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
pkg/model/dynamic-plugins.go	`80.28% <90.90%> (+2.83%)`	⬆️

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

rhdh-qodo-merge · 2026-06-25T19:52:03Z

Code Review by Qodo

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

Context used

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

1. ~~Legacy disable override ignored~~ ✓ Resolved 🐞 Bug ≡ Correctness ⭐ New

Description

MergePluginsData() keeps an existing non-nil Enabled value when an overlay plugin omits enabled,
so a base enabled: true survives even if the overlay sets legacy disabled: true. Because
IsDisabled() gives Enabled precedence, those legacy overlays can no longer disable the plugin
after merging.

Code

pkg/model/dynamic-plugins.go[R297-299]

+			if plugin.Enabled != nil {
+				existingPlugin.Enabled = plugin.Enabled
+			}

Relevance

⭐⭐⭐ High
Merge/disable semantics regressions are treated as bugs; prior fixes around dynamic-plugins merge
behavior were accepted (#1486, #2292).
PR-#1486
PR-#2292

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

IsDisabled() returns !*Enabled whenever Enabled != nil, ignoring Disabled. The merge keeps
the base Enabled unless the overlay explicitly sets enabled, so an overlay that only sets legacy
disabled: true cannot override a base enabled: true. This merge function is used to merge user
config onto defaults, so the regression impacts real override behavior.

pkg/model/dynamic-plugins.go[62-70]
pkg/model/dynamic-plugins.go[125-130]
pkg/model/dynamic-plugins.go[275-305]
PR-#1486

Agent prompt

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

### Issue description
`MergePluginsData()` only copies `Enabled` when the overlay explicitly sets it. If the base/default config has `enabled: true` (so `Enabled != nil`) and a user overlay still uses legacy `disabled: true` without `enabled`, the merged plugin keeps `Enabled=true`. Since `IsDisabled()` prioritizes `Enabled`, the user's `disabled: true` is effectively ignored.

### Issue Context
This is especially likely now that defaults/manifests are being migrated to `enabled: ...` while user overrides may still use `disabled: ...`.

### Fix Focus Areas
- pkg/model/dynamic-plugins.go[297-299]

### Suggested fix
Adjust the merge logic so that an overlay using legacy `disabled: true` can still disable a plugin even when the base has `Enabled` set.

One minimal approach:
- If `plugin.Enabled == nil` and `plugin.Disabled == true`, set `existingPlugin.Enabled` to a non-nil false value (e.g., `b := false; existingPlugin.Enabled = &b`) so `IsDisabled()` will correctly evaluate to disabled.

Also add/adjust a unit test demonstrating:
- Base YAML: `enabled: true`
- Overlay YAML: `disabled: true` (no `enabled`)
- Expected merged effective state: disabled

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

2. ~~Plugin state reset merge~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

MergePluginsData() unconditionally overwrites Enabled/Disabled from the overlay plugin entry, so an
overlay that omits those fields can silently flip a previously-disabled plugin to enabled. This can
change which plugins (and dependency resources) are treated as active after reconciliation.

Code

pkg/model/dynamic-plugins.go[R297-299]

+			existingPlugin.Enabled = plugin.Enabled
			existingPlugin.Disabled = plugin.Disabled
			pluginMap[plugin.Package] = existingPlugin

Relevance

⭐⭐⭐ High
Team historically tightens MergePluginsData semantics to preserve state unless explicitly overridden
(includes/deps) and preserve disabled behavior.
PR-#1486
PR-#2292
PR-#2262

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The merge implementation assigns existingPlugin.Enabled = plugin.Enabled and
existingPlugin.Disabled = plugin.Disabled without checking whether the overlay specified those
fields, so zero-values from the overlay overwrite the base state. The existing merge test sets
plugin-d to disabled: true in the base, but includes plugin-d in the overlay without any
enable/disable field—under the current merge logic, that overlay entry will reset the disabled flag
to false (and clear Enabled), effectively enabling plugin-d.

pkg/model/dynamic-plugins.go[275-303]
pkg/model/dynamic-plugins_test.go[383-439]
PR-#1486

Agent prompt

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

## Issue description
`MergePluginsData()` overwrites `existingPlugin.Enabled` and `existingPlugin.Disabled` unconditionally. Because `Enabled` is a `*bool` and `Disabled` is a plain `bool`, an overlay that does not specify either field produces `Enabled=nil` and `Disabled=false` (zero value) and will therefore reset a previously-disabled plugin to enabled.

## Issue Context
This regression becomes more likely now that repo YAMLs are being migrated away from explicit `disabled: true/false` entries, making “field omitted” a common case.

## Fix Focus Areas
- pkg/model/dynamic-plugins.go[53-70]
- pkg/model/dynamic-plugins.go[275-303]
- pkg/model/dynamic-plugins_test.go[383-497]

### Suggested implementation direction
1. Make `Disabled` tri-state so merges can detect presence:
  - Change `Disabled bool `yaml:"disabled"`` to `Disabled *bool `yaml:"disabled,omitempty"`` (or add a custom unmarshal that tracks whether `disabled` was set).
2. Update `IsDisabled()` to resolve:
  - if `Enabled != nil` => `return !*Enabled`
  - else if `Disabled != nil` => `return *Disabled`
  - else => `return false`
3. Update merge behavior:
  - Only overwrite `existingPlugin.Enabled` when `plugin.Enabled != nil`.
  - Only overwrite `existingPlugin.Disabled` when `plugin.Disabled != nil`.
4. Add/adjust a unit test that explicitly covers: base plugin disabled, overlay modifies other fields but omits enable/disable, merged result must remain disabled.

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

3. enabled merge undocumented 📘 Rule violation ⚙ Maintainability ⭐ New

Description

MergePluginsData now conditionally merges the new enabled field, which changes user-facing
override/merge behavior for dynamic plugins. The documentation does not describe the
enabled/disabled precedence and merge/override semantics for this new field, which can lead to
incorrect configurations.

Code

pkg/model/dynamic-plugins.go[R297-299]

+			if plugin.Enabled != nil {
+				existingPlugin.Enabled = plugin.Enabled
+			}

Relevance

⭐⭐⭐ High
Team often updates docs when merge/override semantics change (dynamic-plugins docs updates accepted
in #2292, #2262).
PR-#2292
PR-#2262

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The code change adds conditional merge behavior for enabled, meaning merge/override semantics now
depend on whether enabled is set (nil vs non-nil). The docs describe dynamic plugin merging only
at a high level and provide examples using enabled, but do not document the new field’s
precedence/merge semantics, which is required when implementation behavior changes.

pkg/model/dynamic-plugins.go[297-299]
docs/configuration.md[750-753]
docs/dynamic-plugins.md[128-148]
Best Practice: Repository guidelines

Agent prompt

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

## Issue description
`MergePluginsData` introduced/updated merge behavior for the new `enabled` field (only overwriting when explicitly set). Docs should explicitly state how `enabled` behaves (default, precedence vs `disabled` for backward compatibility) and how it participates in merge/override.

## Issue Context
Users rely on docs to understand how default dynamic plugins config merges with CR-provided config. Adding `enabled` as a new field (with conditional merge) is a user-facing behavior change that should be documented per compliance requirements.

## Fix Focus Areas
- pkg/model/dynamic-plugins.go[297-299]
- docs/configuration.md[750-753]
- docs/dynamic-plugins.md[128-148]

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

Previous review results

Review updated until commit 3c99a18

Results up to commit b466939

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

1. Plugin state reset merge 🐞 Bug ≡ Correctness

Description

MergePluginsData() unconditionally overwrites Enabled/Disabled from the overlay plugin entry, so an
overlay that omits those fields can silently flip a previously-disabled plugin to enabled. This can
change which plugins (and dependency resources) are treated as active after reconciliation.

Code

pkg/model/dynamic-plugins.go[R297-299]

+			existingPlugin.Enabled = plugin.Enabled
			existingPlugin.Disabled = plugin.Disabled
			pluginMap[plugin.Package] = existingPlugin

Relevance

⭐⭐⭐ High
Team historically tightens MergePluginsData semantics to preserve state unless explicitly overridden
(includes/deps) and preserve disabled behavior.
PR-#1486
PR-#2292
PR-#2262

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The merge implementation assigns existingPlugin.Enabled = plugin.Enabled and
existingPlugin.Disabled = plugin.Disabled without checking whether the overlay specified those
fields, so zero-values from the overlay overwrite the base state. The existing merge test sets
plugin-d to disabled: true in the base, but includes plugin-d in the overlay without any
enable/disable field—under the current merge logic, that overlay entry will reset the disabled flag
to false (and clear Enabled), effectively enabling plugin-d.

pkg/model/dynamic-plugins.go[275-303]
pkg/model/dynamic-plugins_test.go[383-439]
PR-#1486

Agent prompt

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

## Issue description
`MergePluginsData()` overwrites `existingPlugin.Enabled` and `existingPlugin.Disabled` unconditionally. Because `Enabled` is a `*bool` and `Disabled` is a plain `bool`, an overlay that does not specify either field produces `Enabled=nil` and `Disabled=false` (zero value) and will therefore reset a previously-disabled plugin to enabled.

## Issue Context
This regression becomes more likely now that repo YAMLs are being migrated away from explicit `disabled: true/false` entries, making “field omitted” a common case.

## Fix Focus Areas
- pkg/model/dynamic-plugins.go[53-70]
- pkg/model/dynamic-plugins.go[275-303]
- pkg/model/dynamic-plugins_test.go[383-497]

### Suggested implementation direction
1. Make `Disabled` tri-state so merges can detect presence:
  - Change `Disabled bool `yaml:"disabled"`` to `Disabled *bool `yaml:"disabled,omitempty"`` (or add a custom unmarshal that tracks whether `disabled` was set).
2. Update `IsDisabled()` to resolve:
  - if `Enabled != nil` => `return !*Enabled`
  - else if `Disabled != nil` => `return *Disabled`
  - else => `return false`
3. Update merge behavior:
  - Only overwrite `existingPlugin.Enabled` when `plugin.Enabled != nil`.
  - Only overwrite `existingPlugin.Disabled` when `plugin.Disabled != nil`.
4. Add/adjust a unit test that explicitly covers: base plugin disabled, overlay modifies other fields but omits enable/disable, merged result must remain disabled.

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

Sign in to view

+			existingPlugin.Enabled = plugin.Enabled
 			existingPlugin.Disabled = plugin.Disabled
 			pluginMap[plugin.Package] = existingPlugin


Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

gazarenkov · 2026-07-02T07:51:01Z

Sign in to view

+			if plugin.Enabled != nil {
+				existingPlugin.Enabled = plugin.Enabled
+			}


@hopehadfield look at this please

rhdh-qodo-merge · 2026-06-30T19:40:44Z

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

gazarenkov

As we claim backward compatibility, related tests required.

See also comment from qodo, it is related.

gazarenkov · 2026-07-02T07:51:01Z

+			if plugin.Enabled != nil {
+				existingPlugin.Enabled = plugin.Enabled
+			}


@hopehadfield look at this please

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

sonarqubecloud · 2026-07-06T19:44:46Z

Quality Gate passed

Issues
2 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 added 2 commits June 25, 2026 15:37

chore: replace disabled with enabled in DP configs

cec223f

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

chore: update docs

b466939

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

hopehadfield requested a review from a team as a code owner June 25, 2026 19:43

openshift-ci Bot requested review from OpinionatedHeron and rm3l June 25, 2026 19:43

hopehadfield marked this pull request as draft June 25, 2026 19:44

openshift-ci Bot added the do-not-merge/work-in-progress label Jun 25, 2026

rhdh-qodo-merge Bot reviewed Jun 25, 2026

View reviewed changes

Comment thread pkg/model/dynamic-plugins.go Outdated

Comment on lines 297 to 299

existingPlugin.Enabled = plugin.Enabled

existingPlugin.Disabled = plugin.Disabled

pluginMap[plugin.Package] = existingPlugin

This comment was marked as resolved.

Sign in to view

rhdh-qodo-merge Bot added documentation Improvements or additions to documentation enhancement New feature or request Tests labels Jun 25, 2026

rm3l mentioned this pull request Jun 26, 2026

chore(rhdh-operator): update branch protection rules openshift/release#81092

Merged

chore: check enabled is not nil

b1b4040

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

hopehadfield marked this pull request as ready for review June 30, 2026 19:21

openshift-ci Bot removed the do-not-merge/work-in-progress label Jun 30, 2026

openshift-ci Bot requested a review from subhashkhileri June 30, 2026 19:21

rhdh-qodo-merge Bot reviewed Jun 30, 2026

View reviewed changes

gazarenkov requested changes Jul 2, 2026

View reviewed changes

openshift-ci Bot assigned gazarenkov Jul 2, 2026

hopehadfield added 2 commits July 6, 2026 12:27

fix disabled logic

54f0e06

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

chore: add additional test cases for backwards compat

3c99a18

Signed-off-by: Hope Hadfield <hhadfiel@redhat.com>

hopehadfield requested a review from a team as a code owner July 6, 2026 19:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore: replace disabled with enabled in DP configs#3098

chore: replace disabled with enabled in DP configs#3098
hopehadfield wants to merge 5 commits into
redhat-developer:mainfrom
hopehadfield:replace-disabled

hopehadfield commented Jun 25, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jun 25, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Jun 25, 2026 •

edited

Loading

Uh oh!

rhdh-qodo-merge Bot commented Jun 25, 2026 •

edited

Loading

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

gazarenkov Jul 2, 2026

Uh oh!

rhdh-qodo-merge Bot commented Jun 30, 2026

Uh oh!

gazarenkov left a comment

Uh oh!

gazarenkov Jul 2, 2026

Uh oh!

sonarqubecloud Bot commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

hopehadfield commented Jun 25, 2026

Description

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

PR acceptance criteria

How to test changes / Special notes to the reviewer

Building Container Images for Testing

Uh oh!

rhdh-qodo-merge Bot commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary by Qodo

Uh oh!

codecov Bot commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

rhdh-qodo-merge Bot commented Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

gazarenkov Jul 2, 2026

Choose a reason for hiding this comment

Uh oh!

rhdh-qodo-merge Bot commented Jun 30, 2026

Uh oh!

gazarenkov left a comment

Choose a reason for hiding this comment

Uh oh!

gazarenkov Jul 2, 2026

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Jul 6, 2026

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rhdh-qodo-merge Bot commented Jun 25, 2026 •

edited

Loading

codecov Bot commented Jun 25, 2026 •

edited

Loading

rhdh-qodo-merge Bot commented Jun 25, 2026 •

edited

Loading