Hey folks, anyone have strong feelings about a hypothetical

experimental-deploy --dry-run

? I think it's a common-enough feature of infra/deployables that we can standardise it in Pants, and I'm pretty sure we could write an opt-in/out mechanism for individual backends. This MR adds an implementation for that for the Terraform backend. Helm implements dry-run with passthrough args, although that strategy doesn't work for backends where the command is different (instead of just the flags. eg for Terrraform that's apply/plan)

Just to be clear I am in no way against the flag itself, it was more a reflection on OP mentioning that helm does it differently. And the more niche the commands get the harder it is to present a unified interface, as even dry running can be ambiguous.

I don't have strong feelings, and would be cautiously in favor. A backend that doesn't support dry runs could simply fail on a dry run attempt.

I think it makes sense. Although has anyone thought about how the plan->apply workflow would work in terms of saving the plan output for the apply step? In this sense, terraform

plan

is more than a dry-run - it's calculating the changes that will be applied.

Backends with an incompatible notion of dry-run could add clarifying options. Something like:

pants experimental-deploy --dry-run --terraform-dry-run=plan ...

I think it makes sense. Although has anyone thought about how the plan->apply workflow would work in terms of saving the plan output for the apply step?

In this sense, terraform plan is more than a dry-run - it's calculating the changes that will be applied.

We use Bazel for our infra at work, but we don't use plan for this capability either. When we apply we review the changes in-situ while holding the lock. So we actually only use plan as a dry-run/preview as well.

Thanks everyone for weighing in. Tom, you brought up very good points. You're right that there are many verbs in the infra world that don't map well onto Pants actions. Your example of Kubernetes dry-run having options of client/server side shows that. Rhys's point about saving a Terraform plan and applying it also illustrates that: sometimes even "deploying" doesn't map to a single verb. Then, of course, there are all the other things you could do with these tools (for some idiosyncratic ones: terraform's

import

, helm's

rollback

). In previous discussions about the Pants deploying things, one key point was that Pants should focus on what it's good at. Pants doesn't focus on all the details of deployments, but does focus on user-friendliness and extensibility. I think having a standardised way of doing the most common actions supports the user-friendliness, and then per-backend options (like suggested by Andreas) supports the extensibility. I think that a "deploy" and a "preview" are those common actions, and I think we've got support for that in this thread. I'll review the MR soon (hopefully tonight!) so we can get it merged. Users could also use Pants to

export

all the dependencies for a deployment to do more advanced operations. I'm currently doing some work to get the Terraform backend to support that.

I agree --dry-run is a good general starting point. I'm excited to see what's coming - yet to try out the terraform backend but hopefully soon.