Suggestion
tofu-apply has no way to skip its own apply step when the plan it regenerates internally turns out to be a no-op, when plan and apply happen in separate workflow runs, e.g. a pull_request-triggered plan workflow and a push-triggered apply workflow. That split is a common pattern for gating applies on merge rather than on PR approval alone.
tofu-apply already regenerates a fresh plan internally and compares it against the PR comment before applying, so it already knows at that point whether there are 0 changes. It just always proceeds to apply regardless.
The workaround from #333 (tofu-plan then a conditional tofu-apply, both in the same job) only works when plan and apply share one job graph in the same workflow run. It doesn't help the split-workflow pattern above, since:
- Passing the PR-time
plan_path forward is explicitly unsafe per the tofu-apply docs: "It does not account for any changes that have occurred since it was generated."
- Adding a second live
tofu-plan step inside the apply workflow works, but triples planning work on every change-laden run: the PR's plan, tofu-apply's own internal plan-vs-comment comparison, and the new pre-check.
The Ask
A skip_no_changes (or similarly named) input on tofu-apply would let it exit cleanly as a no-op once its own internal plan comes back empty (and optionally matches the PR's empty plan), instead of proceeding to apply anyway. No new output to wire up, no caller-side conditional needed, and no extra plan invocation, it's the same internal plan tofu-apply already generates.
Happy to open a PR against a rough shape if one sounds right, or if there's already a preferred design let me know.
Related: #333, a similar gap for auto-merging no-op plans.
Suggestion
tofu-applyhas no way to skip its own apply step when the plan it regenerates internally turns out to be a no-op, when plan and apply happen in separate workflow runs, e.g. apull_request-triggered plan workflow and apush-triggered apply workflow. That split is a common pattern for gating applies on merge rather than on PR approval alone.tofu-applyalready regenerates a fresh plan internally and compares it against the PR comment before applying, so it already knows at that point whether there are 0 changes. It just always proceeds to apply regardless.The workaround from #333 (
tofu-planthen a conditionaltofu-apply, both in the same job) only works when plan and apply share one job graph in the same workflow run. It doesn't help the split-workflow pattern above, since:plan_pathforward is explicitly unsafe per thetofu-applydocs: "It does not account for any changes that have occurred since it was generated."tofu-planstep inside the apply workflow works, but triples planning work on every change-laden run: the PR's plan,tofu-apply's own internal plan-vs-comment comparison, and the new pre-check.The Ask
A
skip_no_changes(or similarly named) input ontofu-applywould let it exit cleanly as a no-op once its own internal plan comes back empty (and optionally matches the PR's empty plan), instead of proceeding to apply anyway. No new output to wire up, no caller-side conditional needed, and no extra plan invocation, it's the same internal plantofu-applyalready generates.Happy to open a PR against a rough shape if one sounds right, or if there's already a preferred design let me know.
Related: #333, a similar gap for auto-merging no-op plans.