opa eval: Evaluate Rego Policy Against Input
opa eval runs a Rego query against input and data and prints the result, exiting non-zero with --fail when the result is undefined.
opa eval is how you exercise a Rego policy in a pipeline: feed it JSON input, point at your .rego files, and gate on the decision. --fail turns an undefined or empty result into a build failure.
What it does
opa eval loads Rego modules and data with -d, takes an input document with -i, and evaluates the query you pass as the final argument. It prints the result set as JSON. With --fail it exits 1 when the result is undefined; --fail-defined does the inverse.
Common usage
# evaluate a deny rule against a manifest
opa eval -i input.json -d policy.rego 'data.main.deny' --format pretty
# fail the job if any deny message is produced
opa eval -i input.json -d policy/ 'data.main.deny[x]' --fail-defined
# evaluate with both data and policy directories
opa eval -d policy/ -d data.json -i input.json 'data.main.allow'Options
| Flag | What it does |
|---|---|
| -d, --data <path> | Load Rego or JSON/YAML data from a file or directory |
| -i, --input <file> | Input document to evaluate against |
| --format <fmt> | Output format: json, pretty, values, bindings, raw |
| --fail | Exit 1 if the result is undefined or empty |
| --fail-defined | Exit 1 if the result is defined (useful for deny rules) |
| -b, --bundle <path> | Load a bundle directory or tarball |
In CI
Use --fail-defined against a deny rule so the presence of any violation message fails the PR. Pipe a rendered manifest through with -i and keep policies in a versioned policy/ directory. opa eval is stateless, so it runs identically on any runner without a network.
Common errors in CI
"rego_parse_error: unexpected ... token" means a syntax error in a .rego file (often a missing := or a stray brace); the message includes the file and line. "1 error occurred: ... rego_type_error" flags a type mismatch. "undefined function data.x" means the referenced rule or import does not exist. An empty [] result with no --fail flag exits 0, silently passing; add --fail-defined to actually gate.
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