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.

For example:

make create-operator-namespace \
  IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
  VERSION=0.11.0-pr-3163-1118bc3a \
  PROFILE=rhdh

if oc get crd clusterextensions.olm.operatorframework.io &>/dev/null; then \
  make catalog-update-olmv1 deploy-olmv1 \
    IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
    VERSION=0.11.0-pr-3163-1118bc3a \
    PROFILE=rhdh; \
else \
  make catalog-update-openshift deploy-olm-openshift \
    IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
    VERSION=0.11.0-pr-3163-1118bc3a \
    PROFILE=rhdh; \
fi

Wait about 30 seconds for OLM v1 to reconcile, then run each check:

# Should show Serving: True
oc get clustercatalog rhdh-operator

# Should show Installed: True (may take up to 60s)
oc get clusterextension rhdh-operator

# Operator pod should be Running
oc get pods -n rhdh-operator

# CRD should exist
oc get crd backstages.rhdh.redhat.com

smoke test

cat <<'EOF' | oc apply -f -
apiVersion: rhdh.redhat.com/v1alpha5
kind: Backstage
metadata:
  name: fbc-test
  namespace: rhdh-operator
spec:
  application:
    replicas: 1
  database:
    enableLocalDb: true
EOF

oc wait --for=condition=Available deployment/backstage-fbc-test -n rhdh-operator --timeout=600s
oc get pods -n rhdh-operator

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (2) 📘 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

✅ 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 ✓ Resolved 🐞 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 ✓ Resolved 📘 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 3c9c5c7

Results up to commit 3279263

🐞 Bugs (1) 📘 Rule violations (1) 📎 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 ✓ Resolved 🐞 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 ✓ Resolved 📘 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

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Qodo is busy working

Check back in a few minutes. Qodo's code review agents are on it.

[Fortune-Ndlovu]

/build-images

[github-actions]

✅ PR images built successfully!

Images are available for testing:

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

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]

$ make create-operator-namespace \
  IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
  VERSION=0.11.0-pr-3163-1118bc3a \
  PROFILE=rhdh
kubectl create namespace  rhdh-operator
namespace/rhdh-operator created

$ if oc get crd clusterextensions.olm.operatorframework.io &>/dev/null; then \
  make catalog-update-olmv1 deploy-olmv1 \
    IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
    VERSION=0.11.0-pr-3163-1118bc3a \
    PROFILE=rhdh; \
else \
  make catalog-update-openshift deploy-olm-openshift \
    IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
    VERSION=0.11.0-pr-3163-1118bc3a \
    PROFILE=rhdh; \
fi
kubectl delete clustercatalog rhdh-operator --ignore-not-found
sed "s/{{CATALOG_IMG}}/quay.io\/rhdh-community\/operator-catalog:0.11.0-pr-3163-1118bc3a/g" config/samples/catalog-cluster-catalog-template.yaml | \
        sed "s/{{PROFILE_SHORT}}/rhdh/g" | \
        kubectl apply -f -
clustercatalog.olm.operatorframework.io/rhdh-operator created
sed "s/{{BUNDLE_METADATA_PACKAGE_NAME}}/rhdh/g" config/samples/catalog-cluster-extension-template.yaml | \
        sed "s/{{PROFILE_SHORT}}/rhdh/g" | \
        sed "s/{{OPERATOR_NAMESPACE}}/ rhdh-operator/g" | \
        kubectl apply -f -
serviceaccount/rhdh-operator-installer created
clusterrolebinding.rbac.authorization.k8s.io/rhdh-operator-installer-binding created
clusterextension.olm.operatorframework.io/rhdh-operator created

$ oc get clustercatalog rhdh-operator
NAME            LASTUNPACKED   SERVING   AGE
rhdh-operator   96s            True      99s
fndlovu@fndlovu-thinkpadp1gen7:~/Documents/RHIDP-14658-operator-update-build-tooling-to-produce-olm-v-1-compatible-fbc-catalogs/rhdh-operator$ oc get clusterextension rhdh-operator
NAME            INSTALLED BUNDLE                         VERSION                   INSTALLED   PROGRESSING   AGE
rhdh-operator   rhdh-operator.v0.11.0-pr-3163-1118bc3a   0.11.0-pr-3163-1118bc3a   True        True          102s

$ oc get pods -n rhdh-operator
NAME                             READY   STATUS    RESTARTS   AGE
rhdh-operator-5fc5d89696-5ttbb   1/1     Running   0          102s
fndlovu@fndlovu-thinkpadp1gen7:~/Documents/RHIDP-14658-operator-update-build-tooling-to-produce-olm-v-1-compatible-fbc-catalogs/rhdh-operator$ oc get crd backstages.rhdh.redhat.com
NAME                         CREATED AT
backstages.rhdh.redhat.com   2026-07-16T10:20:15Z

[gazarenkov]

May be some shoult reference for new command would make sense in docs/developer.md?

[Fortune-Ndlovu]

/build-images

[github-actions]

✅ PR images built successfully!

Images are available for testing:

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

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}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.25%. Comparing base (4bf7524) to head (3c9c5c7).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3163   +/-   ##
=======================================
  Coverage   63.25%   63.25%           
=======================================
  Files          38       38           
  Lines        2316     2316           
=======================================
  Hits         1465     1465           
  Misses        706      706           
  Partials      145      145           

Flag	Coverage Δ
nightly	?
unittests	63.25% <ø> (ø)

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

🚀 New features to boost your workflow:

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

[Fortune-Ndlovu]

/build-images

[github-actions]

✅ PR images built successfully!

Images are available for testing:

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

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]

$ make create-operator-namespace \ 
  IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
  VERSION=0.11.0-pr-3163-b2eff293 \
  PROFILE=rhdh

kubectl create namespace  rhdh-operator
namespace/rhdh-operator created

$ make catalog-update-olmv1 deploy-olmv1 \
  IMAGE_TAG_BASE=quay.io/rhdh-community/operator \
  VERSION=0.11.0-pr-3163-b2eff293 \
  PROFILE=rhdh

kubectl delete clustercatalog rhdh-operator --ignore-not-found
sed "s/{{CATALOG_IMG}}/quay.io\/rhdh-community\/operator-catalog:0.11.0-pr-3163-b2eff293/g" config/samples/catalog-cluster-catalog-template.yaml | \
        sed "s/{{PROFILE_SHORT}}/rhdh/g" | \
        kubectl apply -f -
clustercatalog.olm.operatorframework.io/rhdh-operator created
sed "s/{{BUNDLE_METADATA_PACKAGE_NAME}}/rhdh/g" config/samples/catalog-cluster-extension-template.yaml | \
        sed "s/{{PROFILE_SHORT}}/rhdh/g" | \
        sed "s/{{OPERATOR_NAMESPACE}}/ rhdh-operator/g" | \
        kubectl apply -f -
serviceaccount/rhdh-operator-installer created
clusterrolebinding.rbac.authorization.k8s.io/rhdh-operator-installer-binding created
clusterextension.olm.operatorframework.io/rhdh-operator created

$ oc get clustercatalog rhdh-operator
NAME            LASTUNPACKED   SERVING   AGE
rhdh-operator   13s            True      14s

$ oc get clusterextension rhdh-operator
NAME            INSTALLED BUNDLE                         VERSION                   INSTALLED   PROGRESSING   AGE
rhdh-operator   rhdh-operator.v0.11.0-pr-3163-b2eff293   0.11.0-pr-3163-b2eff293   True        True          3m24s

$ oc get pods -n rhdh-operator
NAME                            READY   STATUS    RESTARTS   AGE
rhdh-operator-b8c96779b-nlvd7   1/1     Running   0          24s

 oc get crd backstages.rhdh.redhat.com
NAME                         CREATED AT
backstages.rhdh.redhat.com   2026-07-16T16:39:14Z

$ cat <<'EOF' | oc apply -f -
apiVersion: rhdh.redhat.com/v1alpha5
kind: Backstage
metadata:
  name: fbc-test
  namespace: rhdh-operator
spec:
  application:
    replicas: 1
  database:
    enableLocalDb: true
EOF
backstage.rhdh.redhat.com/fbc-test created

$ oc get pods -n rhdh-operator
NAME                                  READY   STATUS    RESTARTS   AGE
backstage-fbc-test-78ddd8f679-fhjnh   1/1     Running   0          4m9s
backstage-psql-fbc-test-0             1/1     Running   0          4m9s
rhdh-operator-b8c96779b-nlvd7         1/1     Running   0          4m45s

clean up

$ make undeploy-openshift
make[1]: Entering directory '/home/fndlovu/Documents/RHIDP-14658-operator-update-build-tooling-to-produce-olm-v-1-compatible-fbc-catalogs/rhdh-operator'
kubectl delete clusterextension rhdh-operator --ignore-not-found
clusterextension.olm.operatorframework.io "rhdh-operator" deleted
kubectl delete clustercatalog rhdh-operator --ignore-not-found
clustercatalog.olm.operatorframework.io "rhdh-operator" deleted
kubectl delete clusterrolebinding rhdh-operator-installer-binding --ignore-not-found
clusterrolebinding.rbac.authorization.k8s.io "rhdh-operator-installer-binding" deleted
kubectl -n  rhdh-operator delete serviceaccount rhdh-operator-installer --ignore-not-found
serviceaccount "rhdh-operator-installer" deleted from rhdh-operator namespace
make[1]: Leaving directory '/home/fndlovu/Documents/RHIDP-14658-operator-update-build-tooling-to-produce-olm-v-1-compatible-fbc-catalogs/rhdh-operator'

$ oc get pods -n rhdh-operator
No resources found in rhdh-operator namespace.

[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

[Fortune-Ndlovu]

/build-images

[github-actions]

✅ PR images built successfully!

Images are available for testing:

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

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]

images also work