refactor(dev): single source of truth for the OCM transfer step by cbrgm · Pull Request #733 · opendefensecloud/solution-arsenal

cbrgm · 2026-08-04T13:18:31Z

Background

Part of #644, the context is one command to spin up SolAr locally with the demo app deployed -> make demo. Small PRs:

✅ make make dev-cluster reliably populate the catalog (fix(dev): make dev-cluster reliably populate the catalog #731)
(this PR) single source of truth for the OCM transfer step
make demo-app / make demo / make demo-clean for the full render -> bootstrap flow
a CI smoke test that runs the demo so it cant silently rot

What

extract the OCM transfer into hack/demo/transfer-discovery.sh. setup-discovery.sh calls it, and the upcoming make demo-app flow reuses it
delete the credentials-only test/fixtures/ocmconfig

Why

The transfer invocation and its config were living in more than one place, which is exactly how the drift in #731 happened (dev pointed at a config without the rootcerts block and failed TLS). Now theres one helper for the transfer step and one config -> test/fixtures/e2e/ocmconfig, which both the dev scripts and the e2e suite already use, so the config cant drift between them.

The old top-level test/fixtures/ocmconfig was the actual footgun (credentials only, no CA trust), so I deleted it

e2e is left untouched -> it keeps its own Go transfer and just references the same single config. Rewiring it to shell out to the helper would change e2e behavior for no real gain (the config, the thing that drifted, is already shared). The behavioral no-drift across the whole flow comes from the demo smoke test in step 4.

Testing

$ shellcheck hack/demo/transfer-discovery.sh test/fixtures/setup-discovery.sh   # clean

# against a live dev cluster, catalog cleared first:
$ OCM=./bin/go/ocm bash test/fixtures/setup-discovery.sh
...
Transferring ocm-demo component via OCM...
Transfer done. ...
# ~15s later, via scan:
$ kubectl -n solar-system get comp,cv
component.../opendefense-cloud-ocm-demo                  10.96.200.10:443   test/opendefense.cloud/ocm-demo
componentversion.../opendefense-cloud-ocm-demo-v26-4-2   opendefense-cloud-ocm-demo   v26.4.2

Exit 0, no leaked port-forward. grep -rn fixtures/ocmconfig confirms nothing references the deleted config anymore (e2e uses e2e/ocmconfig).

Checklist

Tests added/updated (n/a, dev tooling refactor, verified manually against a live kind cluster, e2e unchanged)
No breaking changes (e2e untouched, same single config)
Readable commit history (one focused commit)
AI code review considered and comments resolved

Part of #644

Summary by CodeRabbit

New Features
- Added a command to transfer the OCM demo content to a specified registry.
- Supports custom OCM executable, configuration, and demo directory settings.
Documentation
- Updated setup guidance to require cluster CA trust configuration.
- Simplified demo transfer instructions using the new command.

…e broken ocmconfig The OCM transfer invocation and its config now live in one place, hack/demo/transfer-discovery.sh, which setup-discovery.sh calls and the upcoming make demo-app flow will reuse. This keeps the transfer step from drifting across the demo scripts. Delete the credentials-only test/fixtures/ocmconfig, the footgun that made the documented flow fail TLS. The single remaining config is test/fixtures/e2e/ocmconfig, which both the dev scripts and the e2e suite already use, so the config cannot drift between them. e2e is untouched, it keeps its own Go transfer and just references the same single config.

coderabbitai · 2026-08-04T13:18:50Z

📝 Walkthrough

Walkthrough

The PR adds a reusable script for transferring the OCM demo CTF. Discovery setup now uses the script, requires cluster CA trust in OCM_CONFIG, and removes the obsolete registry fixture.

Changes

Discovery transfer

Layer / File(s)	Summary
Reusable CTF transfer script `hack/demo/transfer-discovery.sh`	Adds strict-mode execution, configurable OCM settings, target validation, and the `ocm transfer ctf` command.
Discovery setup integration `test/fixtures/setup-discovery.sh`, `test/fixtures/ocmconfig`	Documents the required `rootcerts` configuration and invokes the reusable script with environment variables. Deletes the previous registry fixture configuration.

Estimated code review effort: 3 (Moderate) | ~15–30 minutes

Sequence Diagram(s)

sequenceDiagram
  participant setup-discovery.sh
  participant transfer-discovery.sh
  participant OCM
  participant Registry
  setup-discovery.sh->>transfer-discovery.sh: Pass OCM settings and registry URL
  transfer-discovery.sh->>OCM: Run ocm transfer ctf
  OCM->>Registry: Transfer the discovery CTF

Possibly related PRs

opendefensecloud/solution-arsenal#731: Updates discovery setup with CA-trusting OCM configuration and transfer changes.

🚥 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 directly matches the main change: extracting the OCM transfer step into a shared helper script as a single source of truth.
Description check	✅ Passed	The description includes all required template sections: What (extract OCM transfer, delete credentials config), Why (eliminate config drift), Testing (ShellCheck and manual validation), and completed checklist items.

✨ 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 refactor/demo-shared-transfer

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

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

cbrgm · 2026-08-04T13:38:35Z

Wow, this is actually the first time Coderabbit doesn't complain

olzemal

unrelated to this pr, but i noticed $OCM_DEMO_DIR is also not used by dev-cluster.sh anymore.

solution-arsenal/hack/dev-cluster.sh

Line 11 in 39a33df

OCM_DEMO_DIR="${OCM_DEMO_DIR:-$(pwd)/test/fixtures/ocm-demo-ctf}"

cbrgm · 2026-08-05T11:07:19Z

unrelated to this pr, but i noticed $OCM_DEMO_DIR is also not used by dev-cluster.sh anymore.

solution-arsenal/hack/dev-cluster.sh

Line 11 in 39a33df

OCM_DEMO_DIR="${OCM_DEMO_DIR:-$(pwd)/test/fixtures/ocm-demo-ctf}"

Good find, will clean this up in another pr later

…734) ## Background Part of #644, the arc is one command to spin up SolAr locally with the demo app deployed -> `make demo` 1. ✅ make `make dev-cluster` reliably populate the catalog (#731) 2. ✅ single source of truth for the OCM transfer step (#733) 3. **(this PR)** `make demo-app` / `make demo` / `make demo-clean` for the full render -> bootstrap flow 4. a CI smoke test that runs the demo so it cant silently rot ## What Three make targets, backed by two scripts under `hack/demo`: - `make demo-app` -> seeds the ocm-demo app end to end on an existing dev cluster: transfer -> discover -> release -> render -> bootstrap -> running workload. Idempotent. - `make demo` -> from zero: create the dev cluster if its missing, then `demo-app`. - `make demo-clean` -> remove the demo resources and the app namespace, keep the cluster and the catalog. ## Why After `make dev-cluster` we had an empty SolAr and getting the demo app actually deployed was a manual, order-sensitive dance across a few scripts. `demo-app` walks that whole path in one go. The important bit for not drifting: `demo-app` mirrors the exact happy path the e2e suite exercises and reuses the **same** `test/fixtures/e2e` manifests (release, target, registry, bindings, regcred, bootstrap). So the demo and the e2e tests share their inputs and cant diverge. CI will guard the ordering in step 4 (pr follows after this one :)). Topology -> everything runs in `solar-system`, because thats where dev-cluster's discovery writes the ComponentVersion and where the discovery Registry (`zot-scan`) and the `zot-deploy` pull secret already live. So every reference resolves in-namespace, no ReferenceGrants needed. This matches how the e2e suite runs the whole flow in a single namespace. The app itself lands in the Release's `targetNamespace` (`demo`). Re-runs are cheap -> `demo-app` skips the transfer when the ComponentVersion is already in the catalog. ## Testing Full loop against a local kind cluster (`make dev-cluster` first): ``` $ make demo-app >>> Transferring the ocm-demo component and waiting for discovery... >>> ... ocirepository.../solar-bootstrap condition met helmrelease.../solar-bootstrap condition met $ kubectl -n solar-system get releases,rendertasks,renderartifacts release/...-release ... Resolved rendertask/render-rel-... Target cluster-1 JobSucceeded rendertask/render-tgt-cluster-1-0 Target cluster-1 JobSucceeded renderartifact/... solar-system/bootstrap-cluster-1 v0.0.0 $ kubectl -n demo get pods solar-bootstrap-opendefense-cloud-ocm-demo-...-demo... 1/1 Running # the demo app is deployed ``` For the person who reviews this, try to run the following locally: - fresh `make demo-app` -> workload Running - `make demo-clean` -> demo resources + `demo` namespace gone, catalog + cluster kept - re-seed from clean -> workload Running again - idempotent re-run with catalog present -> skips the transfer, still reaches Ready - `make shellcheck` clean e2e suite is untouched ## Checklist - [x] Tests added/updated (n/a, dev tooling, verified manually end to end against a live kind cluster; reuses the e2e fixtures; CI smoke test lands in the follow-up PR) - [x] No breaking changes (new targets only, e2e untouched) - [x] Readable commit history (one focused commit) - [ ] AI code review considered and comments resolved Part of #644  ## Summary by CodeRabbit * **New Features** * Added commands to launch a complete demo environment, either using an existing development cluster or creating one as needed. * Added automated demo setup covering namespaces, credentials, registries, releases, rendering, and readiness checks. * Added cleanup support to remove demo resources while preserving the development cluster and shared setup. * Added configurable options, progress reporting, timeout handling, and re-seeding guidance for demo workflows.

@olzemal

## What Remove the now-unused `OCM_DEMO_DIR` and `OCM` variables from `hack/dev-cluster.sh`. ## Why #733 moved the OCM transfer into `hack/demo/transfer-discovery.sh`, so `dev-cluster.sh` doesnt run `ocm` anymore. Both variables were left behind as dead declarations.@olzemal spotted `OCM_DEMO_DIR` in a review on #733 -> `OCM` is dead for the same reason, so go away :) ## Testing ``` $ grep -nE '\bOCM\b|OCM_DEMO_DIR' hack/dev-cluster.sh # nothing left $ make shellcheck # clean ``` No behavior change, the Makefile never passed these to the script (the `ocm-transfer-demo` target owns `OCM` separately). ## Checklist - [x] Tests added/updated (n/a, dead-code removal) - [x] No breaking changes - [x] Readable commit history (one commit) - [x] AI code review considered and comments resolved

## Background Part of #644, the context is one command to spin up SolAr locally with the demo app deployed -> `make demo`. Small PRs: 1. ✅ make `make dev-cluster` reliably populate the catalog (#731) 2. ✅ single source of truth for the OCM transfer step (#733) 3. ✅ `make demo-app` / `make demo` / `make demo-clean` (#734) 4. **(this PR)** a CI smoke test so the demo flow cant silently rot This is the last one, it closes out the story ## What A `Demo Smoke Test` workflow that runs `make demo` (dev-cluster + demo-app) end to end and asserts the demo application actually comes up. ## Why The demo shares its inputs with the e2e suite (same `test/fixtures/e2e` manifests), but the ordering and the make targets live outside the e2e Go test. Without a check they can drift and nobody notices until someone tries the demo. This job is the backstop: it walks the real transfer -> discover -> release -> render -> bootstrap pipeline and fails if the workload doesnt come up. `demo-app` already waits for the bootstrap HelmRelease to become Ready and exits non-zero otherwise, so a green `make demo` is the assertion. The assert step then polls for the demo pod and waits for it to be Ready. It builds SolAr from source rather than reusing the ghcr images, because `dev-cluster.sh` is wired for local images and adding a ghcr values + pull-secret path just for a smoke test wasnt worth it. ## Gating The demo is heavy (builds the images + full cluster), so it follows the same opt-in pattern as docker/helm/e2e: - on PRs -> only runs when the `ok-to-demo` label is set - on `main` -> runs automatically, but only when demo-relevant files change ## Testing - `actionlint` clean on the workflow. - The full flow (`make demo` -> running workload) is verified locally end to end in #734. - Self-validating: this PR carries `ok-to-demo`, so the smoke job runs on it (an earlier revision without the label gating already passed green in CI). ## Checklist - [x] Tests added/updated (this *is* the test, a CI smoke check) - [x] No breaking changes (new workflow only) - [x] Readable commit history (one focused commit) - [x] AI code review considered and comments resolved Part of #644

Merge branch 'main' into refactor/demo-shared-transfer

39a33df

olzemal reviewed Aug 5, 2026

View reviewed changes

olzemal approved these changes Aug 5, 2026

View reviewed changes

cbrgm merged commit 87a9f64 into main Aug 5, 2026
17 checks passed

cbrgm deleted the refactor/demo-shared-transfer branch August 5, 2026 12:07

cbrgm mentioned this pull request Aug 5, 2026

feat(dev): make demo / demo-app / demo-clean for a one-command demo #734

Merged

3 of 4 tasks

This was referenced Aug 6, 2026

ci: demo smoke test that runs make demo end to end #736

Merged

chore(dev): drop the unused OCM vars from dev-cluster.sh #737

Merged

Navigation Menu

Repository navigation

refactor(dev): single source of truth for the OCM transfer step - #733

refactor(dev): single source of truth for the OCM transfer step#733
cbrgm merged 2 commits into
mainfrom
refactor/demo-shared-transfer

cbrgm commented Aug 4, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented Aug 4, 2026 •

edited

Loading

Walkthrough

Changes

Sequence Diagram(s)

Uh oh!

cbrgm commented Aug 4, 2026

Uh oh!

olzemal left a comment

Uh oh!

cbrgm commented Aug 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

cbrgm commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

What

Why

Testing

Checklist

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Uh oh!

cbrgm commented Aug 4, 2026

Uh oh!

olzemal left a comment

Choose a reason for hiding this comment

Uh oh!

cbrgm commented Aug 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cbrgm commented Aug 4, 2026 •

edited

Loading

coderabbitai Bot commented Aug 4, 2026 •

edited

Loading