Repository navigation
ci: demo smoke test that runs make demo end to end - #736
Conversation
Runs 'make demo' (dev-cluster + demo-app) and asserts the demo application comes up, as the backstop that keeps the demo flow from silently drifting from what the e2e suite covers. It builds SolAr from source and reuses the same test/fixtures/e2e manifests the demo applies, so it exercises the real render -> bootstrap pipeline. Gated to demo-relevant paths to keep CI time down.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe pull request adds a GitHub Actions workflow for demo smoke tests. The workflow uses Nix and Cachix, runs ChangesDemo smoke-test validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 @.github/workflows/test-demo.yaml:
- Around line 68-70: Update the workflow step before the existing kubectl wait
to wait until at least one demo pod has been created, using the existing
kind-solar-dev context and demo namespace. Then retain the kubectl wait for
Ready and subsequent pod listing, ensuring the readiness check cannot fail with
no matching resources.
🪄 Autofix
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: 09bdbefe-4cfe-4c11-bb29-0081868d9b2b
📒 Files selected for processing (1)
.github/workflows/test-demo.yaml
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
In the daily, @olzemal mentioned that it would make sense to switch from file paths to an "ok-to-" label. I think this is a way better suited solution compared to providing filepaths. So now one can just add the label "ok-to-demo" and then see check the demo runs through without issues The demo is heavy (it builds the images and stands up a full cluster), so on PRs it is opt-in via the 'ok-to-demo' label, matching how the docker/helm/e2e jobs are gated. On main it runs automatically, but only when demo-relevant files change, to keep CI time down |
|
@coderabbitai review |
|
Background
Part of #644, the context is one command to spin up SolAr locally with the demo app deployed ->
make demo. Small PRs:make dev-clusterreliably populate the catalog (fix(dev): make dev-cluster reliably populate the catalog #731)make demo-app/make demo/make demo-clean(feat(dev): make demo / demo-app / demo-clean for a one-command demo #734)This is the last one, it closes out the story
What
A
Demo Smoke Testworkflow that runsmake 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/e2emanifests), 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-appalready waits for the bootstrap HelmRelease to become Ready and exits non-zero otherwise, so a greenmake demois 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.shis 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:
ok-to-demolabel is setmain-> runs automatically, but only when demo-relevant files changeTesting
actionlintclean on the workflow.make demo-> running workload) is verified locally end to end in feat(dev): make demo / demo-app / demo-clean for a one-command demo #734.ok-to-demo, so the smoke job runs on it (an earlier revision without the label gating already passed green in CI).Checklist
Part of #644
Summary by CodeRabbit