CI/CD for Terraform is tricky. To make life easier, specialised CI systems aka TACOS exist - Terraform Cloud, Spacelift, Atlantis, etc.
But why have 2 CI systems? Why not reuse the async jobs infrastructure with compute, orchestration, logs, etc of your existing CI?
Digger runs terraform natively in your CI and takes care of the other bits - locks, plan artifacts and so on. Demo video
- 👟 Runner-less. Terraform runs in the compute environment of your existing CI such as Github Actions, Gitlab, Argo etc.
- 🪶 Minimal / no backend. Digger's own backend is a serverless function; it is only needed for certain CI environments (eg Gitlab)
- 🔒 Code-level locks. Avoid race conditions across multiple PRs. Similar to Atlantis workflow.
- ☁️ Multi-cloud. At the moment Digger supports AWS and GCP; Azure support coming in April 2023 (yes, in a few weeks).
- 💥 Projects. Allow to isolate terraform runs and locks to a specific directory
- 💥 Terragrunt support
- 💥 Workspaces support
Need a feature that's not listed? Book a community feedback call - we ship fast ✅
- ✅ GCP support. Store PR locks in GCP storage buckets. Shipped in #50
- ✅ Workspaces support. Allow usage of Terraform CLI Workspaces. Shipped in #72
- ✅ Terragrunt support. Config option to run terragrunt wrapper. Shipped in #76
- ✅ Azure support using Storage Account Tables WIP: #122
- ⌚ AWS CodeBuild support
- ⌛ Gitlab Support
- ⌛ Configurable workflows. In addition to Atlantis-style (apply, then merge) also support "apply-only" and "no-lock"
- ⌛ Bitbucket Support
- ⌛ Jenkins Support
This is demo flow with a sample repo using local state - for real world scenario you'll need to configure remote backend (S3 + DynamoDB) and add a workflow file to the root of the repo.
- Fork the demo repository
- Enable Actions (by default workflows won't trigger in a fork)
- In your repository settings > Actions ensure that the Workflow Read and Write permissions are assigned - This will allow the workflow to post comments on your PRs
- Add environment variables into your Github Action Secrets (NOTE: This step is optional if you just want to test out the Action with
null_resource)
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- make a change and create a PR - this will create a lock
- comment
digger plan- terraform plan output will be added as comment. If you don't see a comment (bug) - check out job output - create another PR - plan or apply won’t work in this PR until the first lock is released
- you should see
Locked by PR #1comment. The action logs will display "Project locked" error message.
Digger does not interfere with your remote backend setup. You could be using S3 backend or TF cloud's remote backend or some other way
Digger also doesn't differentiate locks based on statefiles - if a PR is locked, it's locked for all "instances" of state (aka Terraform CLI Workspaces)
state-level locks will keep working normally because are handled by terraform itself (same as in Atlantis)
- We perform anonymous usage tracking. No sensitive or personal / identifyable data is logged. You can see what is tracked in
pkg/utils/usage.go
If you are considering using digger within your organisation please reach out to us.
To contribute to Digger please follow our Contributing guide
Q) Since you're FOSS I assume you plan to monetize by selling support? Or...?
A) We are a vc-backed startup fully focused on this tool; in terms of monetization - we are currently in the process of launching Digger Pro. Check out the features here and feel free to book a demo if interested.