Skip to content

ci(validate-k3s-rabbit): add e2e cluster validation workflow - #1796

Merged
dark-vex merged 6 commits into
mainfrom
ci/k3s-rabbit-e2e
Aug 7, 2026
Merged

ci(validate-k3s-rabbit): add e2e cluster validation workflow#1796
dark-vex merged 6 commits into
mainfrom
ci/k3s-rabbit-e2e

Conversation

@dark-vex

@dark-vex dark-vex commented Aug 6, 2026

Copy link
Copy Markdown
Owner

Summary

  • Adds validate-k3s-rabbit.yml, giving k3s-rabbit its first live e2e coverage (real k3s + real flux install + real reconcile-to-Ready), matching the mechanism already merged for kubenuc/k8s-vms-daniele (ci(kubenuc,k8s-vms): derive top-level cluster resources instead of hand-enumerating #1790-ci(validate-flux-render): work around flate's concurrent-dispatch livelock #1795).
  • Reuses the generic top-level-resource loop (Mechanism 1) verbatim, and the fail-closed per-app loop (Mechanism 2) — extended with two additional resolution tiers not yet needed on this cluster but shared with a companion oc-ampere PR.
  • All 3 of k3s-rabbit's real apps (fluxcd, system-upgrade-controller, teleport-agent) are excluded — each has a real live external side-effect (Slack/GitHub notifications, a k3s upgrade-channel call with node-cordon capability, a Teleport tunnel join). The app loop deploys zero apps by design on every run today; see the in-workflow header comment for exactly what the run still proves and what conditions actually gate the job's exit code.
  • Includes the CHANGED-parsing fix (require a further / after apps/) from day one — this bit the kubenuc/k8s-vms-daniele workflows twice before it became structural there.
  • Comment-only touch to clusters/k3s-rabbit/apps/fluxcd/notifications.yaml exercises the EXCLUDED_APPS skip path and the CHANGED-parsing fix on this workflow's first real run — a diff that only touched the workflow file would prove nothing about the per-app loop (same lesson as PR ci(kubenuc): fail-closed per-app e2e loop with documented EXCLUDED_APPS #1791).

Test plan

  • Mechanism 1 parser tested locally against the real clusters/k3s-rabbit/kustomization.yaml (resolves to system-upgrade-controller.yaml only, flux-instance.yaml/cluster-vars.yaml correctly absent/skipped)
  • CHANGED grep tested against a synthetic diff touching only apps/kustomization.yaml (yields zero bogus app names) and against a diff touching real app files (yields correct app names)
  • EXCLUDED_APPS membership verified for all 3 real apps
  • YAML + pre-commit hooks (check-yaml, trailing-whitespace, gitleaks) pass
  • Real CI run on this PR: confirm Flux bootstrap, GitRepository resolution, charts (teleport-charts) reconciling, top-level system-upgrade-controller Kustomization reaching Ready, and the EXCLUDED_APPS skip path firing for all 3 apps

🤖 Generated with Claude Code

k3s-rabbit had zero live e2e coverage (only offline flate/kubeconform
schema checks) despite being a real production Flux Operator cluster,
unlike kubenuc and k8s-vms-daniele which already got real k3s+Flux e2e
runs. Ports the same top-level-resource loop and fail-closed per-app
loop, but all 3 real apps (fluxcd, system-upgrade-controller,
teleport-agent) are excluded — each has a live external side-effect
(Slack/GitHub notifications, a real k3s upgrade-channel call with
node-cordon capability, a real Teleport tunnel join) — so this run
proves Flux bootstrap, GitRepository resolution, the chart source, and
the top-level system-upgrade-controller install reaching Ready, plus
fail-closed coverage the moment a 4th app is ever added.

The comment-only touch to apps/fluxcd/notifications.yaml exercises the
CHANGED-parsing fix and the EXCLUDED_APPS skip path on this workflow's
first real CI run.

Signed-off-by: Daniele De Lorenzi <2905124+dark-vex@users.noreply.github.com>
The real CI run on this PR failed: "Check resource deployment status"
ran `flux get helmreleases -A` with no `|| true`, and flux's CLI exits
non-zero when it finds zero matching objects ("no HelmRelease objects
found in any namespace") — under GitHub Actions' default bash
`set -eo pipefail`, that failed the whole step and the job.

On k3s-rabbit specifically this isn't a transient flake — zero
HelmReleases exist by design on every run (3/3 real apps excluded, see
the "Deploy infra baseline and changed apps" step's own header
comment, which already claimed this step doesn't gate the job's exit
code; it does, until now). Add `|| true` to both `flux get` calls,
consistent with the "Check for failed reconciliations" step just below
it, which already treats itself as informational-only the same way.

Signed-off-by: Daniele De Lorenzi <2905124+dark-vex@users.noreply.github.com>
@dark-vex
dark-vex enabled auto-merge August 7, 2026 08:11
@dark-vex
dark-vex merged commit b8e5821 into main Aug 7, 2026
19 checks passed
@dark-vex
dark-vex deleted the ci/k3s-rabbit-e2e branch August 7, 2026 08:12
dark-vex added a commit that referenced this pull request Aug 7, 2026
ci(validate-k3s-rabbit): add e2e cluster validation workflow
dark-vex added a commit that referenced this pull request Aug 7, 2026
flux-operator landed on k3s-rabbit via separate PRs (#1799, #1804,
#1805) while the e2e workflow PR (#1796) was still rebasing on top of
them, so it never appeared in that PR's own diff and no live CI run
has exercised the tier-3 real-deploy path for it here — unlike
oc-ampere, where an identical comment-only touch (PR #1797, commit
66d5dfd) already forced that coverage.

A comment-only touch on flux-operator's HelmRelease forces it into
this PR's own DEPLOY_APPS so this run finally exercises that path.
Also corrects several comments/docs that assumed k3s-rabbit deploys
zero real apps by design, stale since flux-operator's addition.

Safety re-verified independently this session via a fresh live `helm
template` render of chart v0.57.0: zero Helm hooks, no FluxInstance
object; the Deployment just starts the operator controller, which
idles until a FluxInstance CR exists. k3s-rabbit's root
kustomization.yaml has no flux-instance.yaml entry, so that CR is
never created during an e2e run — same as oc-ampere.

Signed-off-by: Daniele De Lorenzi <2905124+dark-vex@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant