Skip to main content
Draftt CI scans the Terraform or OpenTofu plan of each pull request against your Draftt policies and shows every violation on the pull request, before the change is applied. Reviewers see which resources break which policy, and what to change, next to the code.

​
How it works

  1. A pull request is opened or updated, and your workflow runs terraform plan as usual.
  2. The Draftt step scrubs the plan JSON on the runner, removing every value Terraform marks sensitive, and uploads the scrubbed copy to Draftt.
  3. Draftt evaluates the changed resources against your policies.
  4. The Draftt CI GitHub App publishes the result as a check and a comment on the pull request.
The step needs no GitHub token, and a policy violation never fails your workflow: the check reports, it does not block.

​
Set up Draftt CI

Two pieces, set up once each:
  1. Install the Draftt CI GitHub App on the repositories that hold your Terraform code. This binds your GitHub organization to your Draftt organization and lets Draftt publish on your pull requests.
  2. Add the Draftt CI GitHub Action to the workflow that produces your plan, with a Draftt access key.

​
What the pull request shows

A Draftt Terraform Policy Scan check and a comment, updated on every push. For each changed resource that violates a policy, you see the resource, the policy, and the change needed, with a link to the line in your code. Draftt CI check on a pull request: two changed resources, each non-compliant with a policy, linked to the line in the Terraform file. The check concludes success when no changed resource violates a policy and neutral when one does. It never concludes failure. This is on purpose: Draftt CI should never block a team on the day it is adopted, so the check reports and lets your reviewers decide. Don’t make it a required status check. When you are ready to enforce, you have two levers:
  • Fail on scan errors. Set fail-on-scan-error: "true" on the Draftt step, and the step fails when the plan could not be scanned, for example because the key is missing.
  • Fail on violations. Read the violation-count output in a later step and fail the job when it is not 0, and make that job a required status check. See Outputs.

​
Next