Describe the solution you'd like
The remote-cluster E2E workflow (.github/workflows/remote-cluster-e2e.yaml) works but has gaps in what it actually proves and how it's structured. This issue tracks follow-ups raised during review. They are improvements to tests and maintainability.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
#4579 (comment)
-
remote-cluster-e2e.yaml does not really prove “no GC churn.” It records a ConstraintTemplatePodStatus UID, sleeps 2 seconds, and checks the UID again. A broken owner-ref cleanup path on pod restart, or delayed delete/recreate churn, could still pass. If this is meant to cover the bug, it should delete/restart a Gatekeeper pod and assert the old pod-owned status is cleaned up and the new one appears only on the management cluster.
-
remote-cluster-e2e.yaml calls this “external data Provider routing,” but it only creates a Provider and checks ProviderPodStatus. It does not deploy the dummy provider service or exercise an external-data policy/admission request. So it proves status routing for ProviderPodStatus, not that external data works cross-cluster. The existing BATS external-data test around test.bats is a better model because it actually deploys the provider and validates admission behavior.
-
The workflow embeds almost the entire test suite as inline shell from remote-cluster-e2e.yaml. That makes it hard to run locally, hard to reuse the repo’s BATS helpers, and easy for CI-only logic to drift from make test-e2e in Makefile.
Move most of the assertions into BATS. I’d keep the GitHub workflow responsible for CI-only orchestration: matrix, checkout, tool install, two Kind clusters, image build/load, deployment, artifact upload. Then call something like:
make test-e2e BATS_TESTS_FILE=test/bats/remote-cluster.bats
or add a small make test-e2e-remote-cluster target.
Cluster creation, image build/load, and log artifact upload can stay in the workflow or Make targets. But the behavioral checks, waits, owner-ref assertions, VAP/webhook enforcement checks, and Provider routing checks belong in BATS so reviewers and contributors can run the same test locally.
Environment:
- Gatekeeper version:
- Kubernetes version: (use
kubectl version):
Describe the solution you'd like
The remote-cluster E2E workflow (
.github/workflows/remote-cluster-e2e.yaml) works but has gaps in what it actually proves and how it's structured. This issue tracks follow-ups raised during review. They are improvements to tests and maintainability.Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
#4579 (comment)
remote-cluster-e2e.yaml does not really prove “no GC churn.” It records a
ConstraintTemplatePodStatusUID, sleeps 2 seconds, and checks the UID again. A broken owner-ref cleanup path on pod restart, or delayed delete/recreate churn, could still pass. If this is meant to cover the bug, it should delete/restart a Gatekeeper pod and assert the old pod-owned status is cleaned up and the new one appears only on the management cluster.remote-cluster-e2e.yaml calls this “external data Provider routing,” but it only creates a
Providerand checksProviderPodStatus. It does not deploy the dummy provider service or exercise an external-data policy/admission request. So it proves status routing forProviderPodStatus, not that external data works cross-cluster. The existing BATS external-data test around test.bats is a better model because it actually deploys the provider and validates admission behavior.The workflow embeds almost the entire test suite as inline shell from remote-cluster-e2e.yaml. That makes it hard to run locally, hard to reuse the repo’s BATS helpers, and easy for CI-only logic to drift from
make test-e2ein Makefile.Move most of the assertions into BATS. I’d keep the GitHub workflow responsible for CI-only orchestration: matrix, checkout, tool install, two Kind clusters, image build/load, deployment, artifact upload. Then call something like:
or add a small
make test-e2e-remote-clustertarget.Cluster creation, image build/load, and log artifact upload can stay in the workflow or Make targets. But the behavioral checks, waits, owner-ref assertions, VAP/webhook enforcement checks, and Provider routing checks belong in BATS so reviewers and contributors can run the same test locally.
Environment:
kubectl version):