[cbrgm]

Background

The final goal (part of #644) is one command to spin up SolAr locally with the demo app actually deployed -> make demo, so onboarding is easy and reproducible. Today make dev-cluster gives you an empty SolAr and getting the demo running is a broken, order-sensitive manual dance. We get there in a few small PRs:

1. (this PR) make make dev-cluster reliably populate the catalog
2. extract a shared OCM transfer step so the dev path and the e2e suite cant drift
3. make demo-app / make demo / make demo-clean to seed the full render -> bootstrap flow
4. Optional but I think worth it: a smoke test which runs in CI that runs the demo so it cant silently rot

Each ships and gets reviewed on its own. This PR is step 1 basically

What

Make make dev-cluster actually populate the catalog out of the box, and fix the discovery transfer helper.

• deploy solar-discovery in scan mode and register the local discovery Zot as a Registry before the worker starts (both dev-cluster.sh and dev-cluster-rebuild). @olzemal had the idea to include that also in the solar helm chart but I would probably like to do it this way for now and then later we can refactor it if we really agree to extend the helm chart in the future. But this is out of scope for now I would say
• setup-discovery.sh now uses the ca-trusting ocmconfig and always cleans up its port-forward

Why

On a fresh dev-cluster the catalog was always empty. Dug into it -> discovery was deployed with no registries, and the pipeline builds its scanners from the registries present at startup (pkg/discovery/pipeline). A Registry added after the worker is already running never gets a scanner, so nothing ever gets discovered. Webhook mode doesnt save us either, its push events are one-shot with no retry and race the listener readiness (i watched zot get connection refused on :8080 and just drop the events).

Scan mode is the reproducible choice for a one command dev setup -> it reconciles on an interval, so timing doesnt matter. Applying the scan Registry before the worker starts means the scanner exists from the first reconcile. e2e is untouched, it manages its own discovery and still covers webhook mode, so no drift there.

Separately, setup-discovery.sh pointed at test/fixtures/ocmconfig, which only carries credentials and has no rootcerts block -> ocm transfer failed TLS against the self-signed zot cert. It now uses test/fixtures/e2e/ocmconfig (the same one e2e uses) and tears the port-forward down via a trap, so a failed transfer doesnt leak it.

Testing

Full clean run from teardown against a local kind cluster:

$ make cleanup-dev-cluster && make dev-cluster
...
DONE

$ kubectl -n solar-system get registry          # auto-wired by dev-cluster, no manual step
NAME       HOSTNAME           PLAIN HTTP   AGE
zot-scan   10.96.200.10:443   false        7s

$ kubectl get comp,cv -A                          # before pushing anything
(empty - correct)

$ OCM=./bin/go/ocm bash test/fixtures/setup-discovery.sh
...
Transferring ocm-demo component via OCM...
Transfer done. ...

$ kubectl -n solar-system get comp,cv             # ~10s later, via scan
NAME                                                            REGISTRY           REPOSITORY
component.../opendefense-cloud-ocm-demo                         10.96.200.10:443   test/opendefense.cloud/ocm-demo
NAME                                                            COMPONENT REF                TAG
componentversion.../opendefense-cloud-ocm-demo-v26-4-2          opendefense-cloud-ocm-demo   v26.4.2

No leaked port-forward afterwards. make shellcheck clean, e2e suite untouched.

Checklist

• Tests added/updated (n/a, dev tooling + docs, verified manually against a live kind cluster, e2e unchanged)
• No breaking changes (e2e manages its own discovery, only the dev/demo path changes)
• Readable commit history (two focused commits)
• AI code review considered and comments resolved

Part of #644

[coderabbitai]

📝 Walkthrough

Walkthrough

Changes

Discovery scan setup

Layer / File(s)	Summary
Scan-mode cluster setup Makefile, hack/dev-cluster.sh, docs/developer-guide/dev-cluster-with-kind.md	Cluster setup applies the discovery registry manifest and deploys Solar Discovery with scan-based values. The guide documents the required tools and scan-mode resources.
Configurable fixture transfer test/fixtures/setup-discovery.sh, docs/developer-guide/dev-cluster-with-kind.md	The fixture configures OCM and local port values, waits for port-forward readiness, cleans up the specific process, and reports scan-created resources.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: trevex

Sequence Diagram(s)

sequenceDiagram
  participant setup_discovery
  participant kubectl
  participant Zot
  participant solar_discovery
  setup_discovery->>kubectl: Apply discovery registry scan manifest
  kubectl->>Zot: Register discovery registry
  setup_discovery->>kubectl: Deploy with scan values
  kubectl->>solar_discovery: Start scan-mode discovery
  solar_discovery->>Zot: Scan registered registry

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: making the development cluster reliably populate the catalog.
Description check	✅ Passed	The description covers the change, motivation, testing, and checklist; only the optional reviewer notes section is absent.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/demo-setup-scripts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 6

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/developer-guide/dev-cluster-with-kind.md`:
- Around line 39-41: Add solar-discovery to the “What Gets Installed” table with
solar-system as its namespace and a description matching its scan-mode local
discovery and automatic catalog population behavior.
- Around line 126-137: Update the environment-variable table in the dev-cluster
guide to include OCM_CONFIG and LOCAL_PORT, documenting each variable’s default
value and purpose consistent with the script’s behavior. Keep the existing
variable entries unchanged.
- Around line 135-137: Update the kubectl inspection command near
setup-discovery.sh to explicitly select the Kind context derived from
KIND_CLUSTER_DEV, matching the target cluster used by the setup flow. Preserve
the existing namespace and resource arguments.
- Around line 135-137: Convert the kubectl command block near the developer
guide’s kind-cluster instructions from fenced Markdown to the repository’s
required four-space indented code-block style, preserving the command unchanged.
- Around line 18-19: Update the OCM command configuration used by dev-cluster
and test/fixtures/setup-discovery.sh so standalone scripts resolve the
Makefile-provisioned binary in bin/ by default, or document the required
OCM=<provisioned-path> environment override in the environment table; keep the
existing Makefile workflow intact.

In `@test/fixtures/setup-discovery.sh`:
- Around line 27-33: Update the port-forward readiness loop in
setup-discovery.sh to track a readiness flag, and fail immediately if pf_pid
exits before the TCP probe succeeds. After the loop, exit nonzero when the flag
is not true so OCM is never run against an unavailable port.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8794e60c-8cd5-4307-a17c-7f39d7c8c148

📥 Commits

Reviewing files that changed from the base of the PR and between fa95810 and eae09f2.

📒 Files selected for processing (4)

• Makefile
• docs/developer-guide/dev-cluster-with-kind.md
• hack/dev-cluster.sh
• test/fixtures/setup-discovery.sh

[coveralls]

Coverage Report for CI Build 30898888452

Coverage remained the same at 82.027%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• 6 coverage regressions across 1 file.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

6 previously-covered lines in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
pkg/controller/rendertask_controller.go	6	86.58%

---

Coverage Stats

Relevant Lines:	6404
Covered Lines:	5253
Line Coverage:	82.03%
Coverage Strength:	32.28 hits per line

---

💛 - Coveralls

[olzemal]

lgtm, i could reproduce the test setup.
A fixed, small scanning interval is probably the most robust way to discover components at the scale of local development.
E2e tests setup the webhook ptr service themselves so this should have no effects on the e2e cluster / tests.