No comments yet.
Unlike other Terraform CI/CD systems, Digger doesn’t run jobs on the server, it is designed [1] in a manner where it can reuse the compute of your CI. We think this approach is superior as it’s scalable (you reuse the compute of your CI) and secure (as no sensitive stuff leaves the privileged environment of your CI)
Digger has 2 components:
- A CLI agent that runs in your CI and interacts with Terraform CLI - An orchestrator backend that responds to events from your VCS and triggers CI jobs
When a PR is opened, Digger starts a CI job that runs *`terraform plan`* and posts plan output as comment. You can then comment “digger apply” to run *`terraform apply`*. Digger can also be configured to run apply only after the PR has been merged, as is preferred by a lot of organisations for their higher environments.
The orchestrator backend is self hostable [2] and does not have access to any sensitive data. It’s only role is to trigger CI jobs, your sensitive data never leaves the high-trust environment of your CI.
For the last 15 months, Digger has been GitHub Actions only. But recently Buildkite support came up in one of the enterprise POCs, and we thought, why not launch it? However, since we’ve built it initially for the Enterprise Edition, you’d need a license key to try it. (it’s much easier to move features from EE to CE than the other way around!)
Here’s a 14 day trial license key you can us to get set up: `DIGGER_LICENSE_KEY`: 4B25EE6C8721BA69A467B7633453A
To set up Digger , ensure you have a valid license key (use the one above) and a Buildkite account with a CI agent. Install the Digger orchestrator using the Docker image/Helm Chart and include the `DIGGER_LICENSE_KEY` environment variable.
Configure Buildkite with the necessary tokens and pipeline settings. Install the Digger CLI on your Buildkite agent and prepare your repo with a `digger.yml` for your Terraform projects. Create a Buildkite pipeline, set your license key, and add a step to invoke Digger. Test the setup by creating a pull request and verifying the webhook events and Buildkite triggers.
We’ve decided internally to ship new features to the enterprise edition first, and then move it to the community edition as removing features from the community just didn’t seem right to us. We’d also love to learn if this is best practice or if there are other ways to split features between CE and EE. We’re currently following Gitlab’s buyer based open core model [3]
Please test it out and let us know what you think, we’d love your feedback!
[1] Digger’s architecture: https://digger.dev/Architecture
[2] Self Host Digger’s Orchestrator Backend: https://docs.digger.dev/self-host/deploy-helm
[3] Gitlab’s buyer based open core model: https://docs.digger.dev/self-host/deploy-helm
