Add MetalLB upstream-style e2e tests under e2etest/ on the user's GitHub fork branch and validate via GitHub Actions; no PR unless user requests. Use in QE Phase 4.
Phase 4 of the MetalLB QE lifecycle: implement automated tests in the product repository’s e2etest/ tree, validated on KIND-based flows in GitHub CI on the user’s GitHub account/fork.
Prerequisite: User explicitly approved completion of Phase 3 (first execution) for this feature set.
metallb/metallb upstream unless the user has it.e2etest/ (and supporting files if required by upstream patterns).tasks.py exposes invoke tasks (run as inv …).inv dev-env (see dev-env/README.md).inv e2etest with flags such as --bgp-mode frr-k8s, --skip, --ginkgo-params (see e2etest/README.md).Example (adjust focus/skip for your tests):
inv dev-env
inv e2etest --skip "IPV6|DUALSTACK|FRR-MODE|L2" --bgp-mode frr-k8s --ginkgo-params "-v --focus 'ConfigurationState'"
Cleanup when done with local KIND: inv dev-env-cleanup.
Confirm gate — User approves automation phase; confirm fork URL, branch name, and target repo (metallb vs metallb-operator vs frr-k8s—most e2e live under metallb/metallb).
Clone and branch — git clone user fork, git checkout -b <test-branch>.
Implement tests — Follow existing e2etest packages, Ginkgo style, and dev-env assumptions documented in upstream e2etest/README.md.
Local sanity (optional but recommended) — If the user’s machine has Docker/KIND and invoke deps, run a narrow inv e2etest focus matching the new tests before relying solely on CI.
Push and CI — Push branch; monitor Actions on the user’s GitHub repo. Use gh run watch / UI as needed. Report workflow conclusion and link to the run.
Response — Summarize: branch name, commits, CI status, and any follow-ups (flakes, skipped suites).
.cursor/workspaces/metallb-repo-analysis/ per project rules..cursor/rules/metallb-qe-lifecycle.mdc phase ordering.