chore: replace SQLite catalog-build with FBC workflow and add OLM v1 deploy targets [RHIDP-14669]

[Fortune-Ndlovu]

Description

This PR replaces the deprecated opm index add (SQLite) catalog-build target with an FBC workflow using opm init + opm render, and adds OLM v1 deploy/undeploy Makefile targets with ClusterCatalog and ClusterExtension templates. OLM v1's catalogd rejects SQLite catalogs missing the operators.operatorframework.io.index.configs.v1 label. FBC catalogs remain backward-compatible with OLM v0 on OCP 4.17+.

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

• Fixes https://redhat.atlassian.net/browse/RHIDP-14669

PR acceptance criteria

• Tests
• Documentation

How to test changes / Special notes to the reviewer

see: https://redhat.atlassian.net/browse/RHIDP-14669?focusedCommentId=17531594

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.

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (2) 📜 Skill insights (0)

Context used

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

✅ Compliance rules (platform): 18 rules

1. Template binds cluster-admin 📘 Rule violation ⛨ Security

Description

The new OLM v1 sample template grants full cluster-wide privileges by binding the installer
ServiceAccount to the built-in cluster-admin role via a ClusterRoleBinding, which is an unsafe
default for an example manifest. If applied as-is (e.g., through the provided make target), this
expands the blast radius if the ServiceAccount is misused or compromised.

Code

config/samples/catalog-cluster-extension-template.yaml[R7-18]

+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: {{PROFILE_SHORT}}-operator-installer-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: cluster-admin
+subjects:
+- kind: ServiceAccount
+  name: {{PROFILE_SHORT}}-operator-installer
+  namespace: {{OPERATOR_NAMESPACE}}

Relevance

⭐⭐⭐ High

Team has history removing overbroad RBAC/permissions; cluster-admin bindings are typically rejected
as unsafe defaults.

PR-#1320
PR-#766
PR-#740

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1 requires runnable example manifests to use safe placeholders and avoid insecure
defaults, but the cited sample manifest explicitly creates a ClusterRoleBinding that binds the
installer ServiceAccount to cluster-admin, which is an excessively broad privilege level for a
template. Additionally, the repository’s make deploy-olmv1 workflow applies this manifest, meaning
the insecure default is likely to be used in practice and grants cluster-wide privileges to that
ServiceAccount when run.

config/samples/catalog-cluster-extension-template.yaml[7-18]
Makefile[428-433]
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
The OLM v1 sample manifest currently creates a `ClusterRoleBinding` that binds the installer ServiceAccount to the built-in `cluster-admin` ClusterRole, granting full cluster-wide privileges by default. This is an unsafe/insecure default for a runnable example/template and should be narrowed, made optional, or clearly separated as a high-privilege development-only option.

## Issue Context
These sample files are intended to be applied by users (e.g., via `make deploy-olmv1`), so including a default `cluster-admin` binding makes it easy to accidentally grant broad privileges cluster-wide. While this may have been added for convenience to enable cluster-scoped install actions, the example should instead define and bind to a dedicated least-privilege `ClusterRole` for the OLM v1 install flow and/or provide an alternate optional path/template if elevated privileges are truly required.

## Fix Focus Areas
- config/samples/catalog-cluster-extension-template.yaml[7-18]

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

---

2. Broken catalog label selector 🐞 Bug ≡ Correctness

Description

The ClusterExtension template selects a catalog via the label
olm.operatorframework.io/metadata.name={{PROFILE_SHORT}}-operator, but the ClusterCatalog template
does not set this label, so the selector can match nothing and the OLM v1 deployment may fail to
resolve its source.

Code

config/samples/catalog-cluster-extension-template.yaml[R32-35]

+      selector:
+        matchLabels:
+          olm.operatorframework.io/metadata.name: {{PROFILE_SHORT}}-operator
+  install:

Relevance

⭐⭐⭐ High

Repo commonly accepts correctness fixes in manifests/templates when mismatches could break install
flows; no contrary evidence found.

PR-#2036
PR-#1406
PR-#1297

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The ClusterExtension uses a matchLabels selector on olm.operatorframework.io/metadata.name, but
the ClusterCatalog template has no metadata.labels at all, so there is nothing for the selector to
match against.

config/samples/catalog-cluster-extension-template.yaml[28-35]
config/samples/catalog-cluster-catalog-template.yaml[1-5]

Agent prompt

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

## Issue description
`ClusterExtension.spec.source.catalog.selector.matchLabels` requires a label that is not present on the `ClusterCatalog` created by `catalog-cluster-catalog-template.yaml`, so the selector can fail to match the intended catalog.

## Issue Context
- `deploy-olmv1` applies `catalog-cluster-extension-template.yaml`.
- `catalog-update-olmv1` applies `catalog-cluster-catalog-template.yaml`.
- The extension’s source selector uses `olm.operatorframework.io/metadata.name`, but the catalog template currently defines only `metadata.name` (not a label).

## Fix Focus Areas
- config/samples/catalog-cluster-extension-template.yaml[28-35]
- config/samples/catalog-cluster-catalog-template.yaml[1-5]

## Suggested fix
Either:
1) Add `metadata.labels.olm.operatorframework.io/metadata.name: {{PROFILE_SHORT}}-operator` to the `ClusterCatalog` template, matching what the `ClusterExtension` selector expects, **or**
2) Change the `ClusterExtension` selector to match a label that is actually set on the `ClusterCatalog` (and ensure that label exists consistently).

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

---

3. Undeploy ignores delete failures 🐞 Bug ☼ Reliability ⭐ New

Description

undeploy-olmv1 uses Make’s error-ignoring - prefix on kubectl delete lines while also using
--ignore-not-found, so RBAC/connection/argument errors are silently swallowed and the target can
succeed while cleanup did not happen.

Code

Makefile[R438-440]

+	-$(KUBECTL) delete clusterextension $(PROFILE_SHORT)-operator --ignore-not-found
+	-$(KUBECTL) delete clusterrolebinding $(PROFILE_SHORT)-operator-installer-binding --ignore-not-found
+	-$(KUBECTL) -n ${OPERATOR_NAMESPACE} delete serviceaccount $(PROFILE_SHORT)-operator-installer --ignore-not-found

Relevance

⭐⭐ Medium

Team accepts targeted error-ignoring (NoMatch/NotFound) but no precedent about removing Makefile ‘-’
on kubectl deletes.

PR-#1552
PR-#1325

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new OLM v1 undeploy commands are prefixed with -, so Make will ignore any non-zero exit from
kubectl even when it’s not a NotFound case. Elsewhere in this Makefile, deletion targets rely on
--ignore-not-found=... without Make’s -, allowing real errors to surface while still being
idempotent for missing objects.

Makefile[436-440]
Makefile[365-376]

Agent prompt

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

## Issue description
`make undeploy-olmv1` currently ignores all failures from `kubectl delete` due to Make's `-` prefix, even though `--ignore-not-found` already provides idempotency for missing resources. This can mislead users into thinking the undeploy succeeded while resources remain.

## Issue Context
GNU Make treats a leading `-` on a recipe line as "ignore non-zero exit status". For deletes, `--ignore-not-found` should be sufficient; other errors (RBAC denial, kube-apiserver unavailable, typo) should fail the target.

## Fix Focus Areas
- Makefile[438-440]

### Suggested change
Remove the leading `-` from these lines and keep `--ignore-not-found` so only NotFound is ignored, but real failures still stop the target.

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

---

4. OLM v1 targets undocumented 📘 Rule violation ⚙ Maintainability

Description

The PR adds new OLM v1 deployment targets and an OLM v0/v1 auto-detect path in the Makefile, but
the developer documentation still only describes the OLM v0 flow, which can lead to incorrect usage
and confusion about version/prerequisites.

Code

Makefile[R428-443]

+.PHONY: deploy-olmv1
+deploy-olmv1: ## Deploy the operator with OLM v1 (ClusterCatalog + ClusterExtension)
+	sed "s/{{BUNDLE_METADATA_PACKAGE_NAME}}/$(subst /,\/,$(BUNDLE_METADATA_PACKAGE_NAME))/g" config/samples/catalog-cluster-extension-template.yaml | \
+		sed "s/{{PROFILE_SHORT}}/$(subst /,\/,$(PROFILE_SHORT))/g" | \
+		sed "s/{{OPERATOR_NAMESPACE}}/$(subst /,\/,$(OPERATOR_NAMESPACE))/g" | \
+		$(KUBECTL) apply -f -
+
+.PHONY: undeploy-olmv1
+undeploy-olmv1: ## Un-deploy the operator with OLM v1
+	-$(KUBECTL) delete clusterextension $(PROFILE_SHORT)-operator
+	-$(KUBECTL) delete clusterrolebinding $(PROFILE_SHORT)-operator-installer-binding
+	-$(KUBECTL) -n ${OPERATOR_NAMESPACE} delete serviceaccount $(PROFILE_SHORT)-operator-installer
+
.PHONY: catalog-update
catalog-update: ## Update catalog source in the default namespace for catalogsource
	-$(KUBECTL) delete catalogsource $(PROFILE_SHORT)-operator -n $(OLM_NAMESPACE)

Relevance

⭐⭐⭐ High

Docs are frequently updated to match behavior; many doc-sync fixes accepted in docs/developer.md and
other docs.

PR-#1807
PR-#2000
PR-#2641

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 4 requires docs to stay synchronized with implementation changes, including
version-specific behavior. The Makefile introduces OLM v1 deploy/update targets and auto-detection
logic, while the developer docs section only documents deploy-olm/undeploy-olm and CatalogSource
updates (no mention of ClusterCatalog/ClusterExtension or auto-detect).

Makefile[428-477]
docs/developer.md[147-178]
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
New OLM v1 deployment/update targets were added (`deploy-olmv1`, `catalog-update-olmv1`, `deploy-openshift-olmv1`, `deploy-openshift-auto`), but developer documentation does not describe these targets, prerequisites (OLM v1 CRDs), or the auto-detection behavior.

## Issue Context
PR Compliance requires documentation to be synchronized with behavior changes, including version boundaries and namespace behavior. The Makefile now supports OLM v1, but docs only cover the legacy OLM (v0) Subscription/CatalogSource approach.

## Fix Focus Areas
- Makefile[428-477]
- docs/developer.md[147-178]

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

---

5. Multi-bundle catalog loses entries 🐞 Bug ≡ Correctness

Description

catalog-build supports comma-separated BUNDLE_IMGS, but it appends a hard-coded olm.channel
with only one entry ($(PROFILE_SHORT)-operator.v$(VERSION)), so additional bundle images rendered
into the catalog won’t be represented in the channel entries.

Code

Makefile[R337-338]

+	$(OPM) render $(BUNDLE_IMGS) --output yaml >> catalog-fbc/catalog.yaml
+	@printf -- '---\nschema: olm.channel\npackage: $(BUNDLE_METADATA_PACKAGE_NAME)\nname: $(DEFAULT_CHANNEL)\nentries:\n  - name: $(PROFILE_SHORT)-operator.v$(VERSION)\n' >> catalog-fbc/catalog.yaml

Relevance

⭐⭐ Medium

No close precedent on multi-bundle FBC channel entries; team often fixes Makefile correctness, but
evidence is indirect.

PR-#2060
PR-#1046
PR-#2870

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Makefile explicitly documents BUNDLE_IMGS as multi-image, but the new printf appends a
channel definition with a single entry, making multi-bundle catalogs incomplete.

Makefile[291-293]
Makefile[334-338]

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 Makefile documents `BUNDLE_IMGS` as a comma-separated list of bundle images, but the new FBC generation logic appends an `olm.channel` document containing exactly one `entries` item. This can produce an incomplete catalog when `BUNDLE_IMGS` includes multiple bundle versions.

## Issue Context
- `BUNDLE_IMGS` is documented as supporting multiple images.
- `catalog-build` renders all bundles in `BUNDLE_IMGS` but does not generate corresponding channel entries for all of them.

## Fix Focus Areas
- Makefile[291-293]
- Makefile[334-338]

## Suggested fix
Update `catalog-build` to generate `olm.channel.entries` for **every** rendered bundle (e.g., derive bundle names from the render output and build the channel doc dynamically), or use an `opm` workflow that generates the channel metadata from the full set of bundles rather than hard-coding a single entry.

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

---

Previous review results

Review updated until commit 744162d

Results up to commit 3279263

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

1. Template binds cluster-admin 📘 Rule violation ⛨ Security

Description

The new OLM v1 sample template grants full cluster-wide privileges by binding the installer
ServiceAccount to the built-in cluster-admin role via a ClusterRoleBinding, which is an unsafe
default for an example manifest. If applied as-is (e.g., through the provided make target), this
expands the blast radius if the ServiceAccount is misused or compromised.

Code

config/samples/catalog-cluster-extension-template.yaml[R7-18]

+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: {{PROFILE_SHORT}}-operator-installer-binding
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: cluster-admin
+subjects:
+- kind: ServiceAccount
+  name: {{PROFILE_SHORT}}-operator-installer
+  namespace: {{OPERATOR_NAMESPACE}}

Relevance

⭐⭐⭐ High

Team has history removing overbroad RBAC/permissions; cluster-admin bindings are typically rejected
as unsafe defaults.

PR-#1320
PR-#766
PR-#740

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1 requires runnable example manifests to use safe placeholders and avoid insecure
defaults, but the cited sample manifest explicitly creates a ClusterRoleBinding that binds the
installer ServiceAccount to cluster-admin, which is an excessively broad privilege level for a
template. Additionally, the repository’s make deploy-olmv1 workflow applies this manifest, meaning
the insecure default is likely to be used in practice and grants cluster-wide privileges to that
ServiceAccount when run.

config/samples/catalog-cluster-extension-template.yaml[7-18]
Makefile[428-433]
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
The OLM v1 sample manifest currently creates a `ClusterRoleBinding` that binds the installer ServiceAccount to the built-in `cluster-admin` ClusterRole, granting full cluster-wide privileges by default. This is an unsafe/insecure default for a runnable example/template and should be narrowed, made optional, or clearly separated as a high-privilege development-only option.

## Issue Context
These sample files are intended to be applied by users (e.g., via `make deploy-olmv1`), so including a default `cluster-admin` binding makes it easy to accidentally grant broad privileges cluster-wide. While this may have been added for convenience to enable cluster-scoped install actions, the example should instead define and bind to a dedicated least-privilege `ClusterRole` for the OLM v1 install flow and/or provide an alternate optional path/template if elevated privileges are truly required.

## Fix Focus Areas
- config/samples/catalog-cluster-extension-template.yaml[7-18]

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

---

2. Broken catalog label selector 🐞 Bug ≡ Correctness

Description

The ClusterExtension template selects a catalog via the label
olm.operatorframework.io/metadata.name={{PROFILE_SHORT}}-operator, but the ClusterCatalog template
does not set this label, so the selector can match nothing and the OLM v1 deployment may fail to
resolve its source.

Code

config/samples/catalog-cluster-extension-template.yaml[R32-35]

+      selector:
+        matchLabels:
+          olm.operatorframework.io/metadata.name: {{PROFILE_SHORT}}-operator
+  install:

Relevance

⭐⭐⭐ High

Repo commonly accepts correctness fixes in manifests/templates when mismatches could break install
flows; no contrary evidence found.

PR-#2036
PR-#1406
PR-#1297

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The ClusterExtension uses a matchLabels selector on olm.operatorframework.io/metadata.name, but
the ClusterCatalog template has no metadata.labels at all, so there is nothing for the selector to
match against.

config/samples/catalog-cluster-extension-template.yaml[28-35]
config/samples/catalog-cluster-catalog-template.yaml[1-5]

Agent prompt

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

## Issue description
`ClusterExtension.spec.source.catalog.selector.matchLabels` requires a label that is not present on the `ClusterCatalog` created by `catalog-cluster-catalog-template.yaml`, so the selector can fail to match the intended catalog.

## Issue Context
- `deploy-olmv1` applies `catalog-cluster-extension-template.yaml`.
- `catalog-update-olmv1` applies `catalog-cluster-catalog-template.yaml`.
- The extension’s source selector uses `olm.operatorframework.io/metadata.name`, but the catalog template currently defines only `metadata.name` (not a label).

## Fix Focus Areas
- config/samples/catalog-cluster-extension-template.yaml[28-35]
- config/samples/catalog-cluster-catalog-template.yaml[1-5]

## Suggested fix
Either:
1) Add `metadata.labels.olm.operatorframework.io/metadata.name: {{PROFILE_SHORT}}-operator` to the `ClusterCatalog` template, matching what the `ClusterExtension` selector expects, **or**
2) Change the `ClusterExtension` selector to match a label that is actually set on the `ClusterCatalog` (and ensure that label exists consistently).

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

---

3. OLM v1 targets undocumented 📘 Rule violation ⚙ Maintainability

Description

The PR adds new OLM v1 deployment targets and an OLM v0/v1 auto-detect path in the Makefile, but
the developer documentation still only describes the OLM v0 flow, which can lead to incorrect usage
and confusion about version/prerequisites.

Code

Makefile[R428-443]

+.PHONY: deploy-olmv1
+deploy-olmv1: ## Deploy the operator with OLM v1 (ClusterCatalog + ClusterExtension)
+	sed "s/{{BUNDLE_METADATA_PACKAGE_NAME}}/$(subst /,\/,$(BUNDLE_METADATA_PACKAGE_NAME))/g" config/samples/catalog-cluster-extension-template.yaml | \
+		sed "s/{{PROFILE_SHORT}}/$(subst /,\/,$(PROFILE_SHORT))/g" | \
+		sed "s/{{OPERATOR_NAMESPACE}}/$(subst /,\/,$(OPERATOR_NAMESPACE))/g" | \
+		$(KUBECTL) apply -f -
+
+.PHONY: undeploy-olmv1
+undeploy-olmv1: ## Un-deploy the operator with OLM v1
+	-$(KUBECTL) delete clusterextension $(PROFILE_SHORT)-operator
+	-$(KUBECTL) delete clusterrolebinding $(PROFILE_SHORT)-operator-installer-binding
+	-$(KUBECTL) -n ${OPERATOR_NAMESPACE} delete serviceaccount $(PROFILE_SHORT)-operator-installer
+
.PHONY: catalog-update
catalog-update: ## Update catalog source in the default namespace for catalogsource
	-$(KUBECTL) delete catalogsource $(PROFILE_SHORT)-operator -n $(OLM_NAMESPACE)

Relevance

⭐⭐⭐ High

Docs are frequently updated to match behavior; many doc-sync fixes accepted in docs/developer.md and
other docs.

PR-#1807
PR-#2000
PR-#2641

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 4 requires docs to stay synchronized with implementation changes, including
version-specific behavior. The Makefile introduces OLM v1 deploy/update targets and auto-detection
logic, while the developer docs section only documents deploy-olm/undeploy-olm and CatalogSource
updates (no mention of ClusterCatalog/ClusterExtension or auto-detect).

Makefile[428-477]
docs/developer.md[147-178]
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
New OLM v1 deployment/update targets were added (`deploy-olmv1`, `catalog-update-olmv1`, `deploy-openshift-olmv1`, `deploy-openshift-auto`), but developer documentation does not describe these targets, prerequisites (OLM v1 CRDs), or the auto-detection behavior.

## Issue Context
PR Compliance requires documentation to be synchronized with behavior changes, including version boundaries and namespace behavior. The Makefile now supports OLM v1, but docs only cover the legacy OLM (v0) Subscription/CatalogSource approach.

## Fix Focus Areas
- Makefile[428-477]
- docs/developer.md[147-178]

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

---

4. Multi-bundle catalog loses entries 🐞 Bug ≡ Correctness

Description

catalog-build supports comma-separated BUNDLE_IMGS, but it appends a hard-coded olm.channel
with only one entry ($(PROFILE_SHORT)-operator.v$(VERSION)), so additional bundle images rendered
into the catalog won’t be represented in the channel entries.

Code

Makefile[R337-338]

+	$(OPM) render $(BUNDLE_IMGS) --output yaml >> catalog-fbc/catalog.yaml
+	@printf -- '---\nschema: olm.channel\npackage: $(BUNDLE_METADATA_PACKAGE_NAME)\nname: $(DEFAULT_CHANNEL)\nentries:\n  - name: $(PROFILE_SHORT)-operator.v$(VERSION)\n' >> catalog-fbc/catalog.yaml

Relevance

⭐⭐ Medium

No close precedent on multi-bundle FBC channel entries; team often fixes Makefile correctness, but
evidence is indirect.

PR-#2060
PR-#1046
PR-#2870

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Makefile explicitly documents BUNDLE_IMGS as multi-image, but the new printf appends a
channel definition with a single entry, making multi-bundle catalogs incomplete.

Makefile[291-293]
Makefile[334-338]

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 Makefile documents `BUNDLE_IMGS` as a comma-separated list of bundle images, but the new FBC generation logic appends an `olm.channel` document containing exactly one `entries` item. This can produce an incomplete catalog when `BUNDLE_IMGS` includes multiple bundle versions.

## Issue Context
- `BUNDLE_IMGS` is documented as supporting multiple images.
- `catalog-build` renders all bundles in `BUNDLE_IMGS` but does not generate corresponding channel entries for all of them.

## Fix Focus Areas
- Makefile[291-293]
- Makefile[334-338]

## Suggested fix
Update `catalog-build` to generate `olm.channel.entries` for **every** rendered bundle (e.g., derive bundle names from the render output and build the channel doc dynamically), or use an `opm` workflow that generates the channel metadata from the full set of bundles rather than hard-coding a single entry.

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

---

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 7c82fe2

[Fortune-Ndlovu]

/build-images

[github-actions]

❌ Image build failed

See workflow run for details: https://github.com/redhat-developer/rhdh-operator/actions/runs/28975714753

Triggered by @Fortune-Ndlovu

[Fortune-Ndlovu]

/build-images

[github-actions]

❌ Image build failed

See workflow run for details: https://github.com/redhat-developer/rhdh-operator/actions/runs/28977474121

Triggered by @Fortune-Ndlovu

[Fortune-Ndlovu]

/build-images

[github-actions]

❌ Image build failed

See workflow run for details: https://github.com/redhat-developer/rhdh-operator/actions/runs/28977899910

Triggered by @Fortune-Ndlovu

[Fortune-Ndlovu]

/build-images

[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

[github-actions]

✅ PR images built successfully!

Images are available for testing:

1. Operator: quay.io/rhdh-community/operator:0.11.0-pr-3163-744162da
2. Bundle: quay.io/rhdh-community/operator-bundle:0.11.0-pr-3163-744162da
3. Catalog: quay.io/rhdh-community/operator-catalog:0.11.0-pr-3163-744162da

Also available with PR number tag:

• quay.io/rhdh-community/operator:0.11.0-pr-3163
• quay.io/rhdh-community/operator-bundle:0.11.0-pr-3163
• quay.io/rhdh-community/operator-catalog:0.11.0-pr-3163

_{Triggered by @Fortune-Ndlovu}

[Fortune-Ndlovu]

nice!

[gazarenkov]

May be consider "if logic" to move to ./hack/ script to keep Makefile a bit lighter?