gator verify: Run Gatekeeper Suite Test Cases
gator verify executes Gatekeeper suite files that declare expected results for each constraint and object, failing when actual admission verdicts diverge from the assertions.
gator verify is the unit-test half of the gator toolkit. You write Suite objects that pair a ConstraintTemplate and Constraint with sample objects and the number of violations each should produce, and gator verify checks the policy still behaves that way.
What it does
gator verify discovers Gatekeeper Suite manifests (kind: Suite in the test.gator group) under a path. Each Suite lists tests, each test references a template and constraint and asserts expected violations (for example assertions with violations: yes/no or a count). It runs them and reports pass/fail per assertion, exiting non-zero on failure.
Common usage
# run all suites under a directory (recursive with ...)
gator verify ./policy/...
# run a single suite directory
gator verify ./policy/require-labels
# only run tests whose name matches a regex
gator verify ./policy/... --run 'missing-label'Options
| Flag | What it does |
|---|---|
| <path> | Directory to search for Suite files; ... suffix recurses |
| --run <regex> | Only run suites/tests whose name matches the regex |
| -v, --verbose | Print detail for passing tests too |
| --include-trace | Include the Rego trace for failing assertions |
In CI
Keep Suite files beside each ConstraintTemplate and run gator verify ./policy/... as a required check in the policy repo. This guards the templates you later run with gator test in service repos, so a policy regression fails where the policy lives, not downstream.
Common errors in CI
A mismatched assertion prints "FAIL" with the suite/test name and expected vs actual, and the process exits 1. "no such file or directory" or an empty run means the path (or the ... suffix) did not match any Suite files. "error creating template" points at a broken ConstraintTemplate, usually a rego_parse_error inside its Rego.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes