conftest --policy: Point at Shared Policy Bundles
conftest --policy (or -p) tells conftest which directory or bundle of Rego policies to load, defaulting to ./policy when omitted.
Real pipelines rarely keep policies in the default ./policy path. --policy lets you centralize rules in a shared bundle and point every repo at the same source of truth, which is the crux of consistent org-wide gates.
What it does
The -p/--policy flag overrides the default policy location for both conftest test and conftest verify. You can repeat it to load multiple directories, and combine it with --data to add non-policy JSON/YAML data documents that the Rego references.
Common usage
# load a specific policy directory
conftest test -p ./ci-policies deployment.yaml
# load multiple policy sources
conftest test -p base-policy/ -p team-policy/ deployment.yaml
# pull a shared bundle first, then test against it
conftest pull ghcr.io/acme/policies:latest
conftest test -p policy/ deployment.yamlOptions
| Flag | What it does |
|---|---|
| -p, --policy <path> | Policy directory or file; repeatable |
| --data <path> | Extra data documents loaded alongside policies |
| -n, --namespace <name> | Which Rego package to evaluate |
| conftest pull <ref> | Download a policy bundle from an OCI registry |
| conftest push <ref> | Publish a policy bundle to an OCI registry |
In CI
Either vendor the policies into each repo for a fully offline check, or conftest pull a versioned OCI bundle at the start of the job and pin the tag. Repeating -p lets a team layer its own rules on top of an org base bundle without forking it.
Common errors in CI
"no policies found in [policy]" is the classic sign that -p points at an empty or wrong path, or that you forgot to conftest pull. "error running command: unable to pull" from conftest pull means a bad registry ref or missing auth. If test passes suspiciously fast, confirm -p actually resolved to the directory that holds your deny rules.