opendefensecloud / solution-arsenal / 30912485537
82%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 71
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 82.058% (+0.03%) from 82.027%
30912485537

push

github

web-flow 
fix(dev): make dev-cluster reliably populate the catalog (#731)

## 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)... (continued)

5255 of 6404 relevant lines covered (82.06%)

34.22 hits per line

Coverage Regressions

Lines Coverage ∆ File
6
86.58
 -0.89% pkg/controller/rendertask_controller.go
Jobs
ID Job ID Ran Files Coverage
1 30912485537.1 71
82.06
 GitHub Action Run
Source Files on build 30912485537