Delete the Terraform state file. Redeploy. Nothing happens. That's the acceptance test: 0 to add,...Delete the Terraform state file. Redeploy. Nothing happens. That's the acceptance test: 0 to add,...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Delete the Terraform state file. Redeploy. Nothing happens.
That's the acceptance test: 0 to add, 0 to change, 0 to destroy. It's the only one I trust here, because it exercises every path at once.
We generate Terraform into customer's own GCP projects, so the starting state is never empty. Rather than create, the generator emits import blocks and adopts what is already there.
But an import block for a resource that doesn't exist is a hard error, so something has to answer "does this exist?" first. That answer is one Cloud Asset Inventory scan, and three times the inventory and Terraform disagreed about what a resource is even called: service accounts by numeric uid rather than email, Firestore by project number rather than project id, and Pub/Sub schemas and Scheduler jobs never returned at all.
Absence from an inventory looks exactly like absence from the cloud. That one cost the most.
Existence isn't enough either. A clean plan would have put a whole tenant on hello-world, because regenerated HCL still carries the placeholder image. Adoption has to ask what each service is actually running, and pin to that.
What's your acceptance test for losing state?
Post image
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started