Question: Why does tfmigrate gate on terraform plan -detailed-exitcode for diffs (including output-only), and can output-only changes be treated as no-op?

[axon-zzhu]

Context

In our migrations, we move resources between modules while legitimately changing module outputs (e.g., renaming/reformatting). No real resources change.

From what we can see, tfmigrate relies on terraform plan -detailed-exitcode to decide whether a migration is “clean.”

Because exit code 2 is returned for any diff (including output-only), tfmigrate treats these as failures.

Using force to proceed despite diffs is too coarse/risky—we want to fail on real resource changes but allow outputs to vary.

Questions

Was relying on the exit code an intentional “any diff = fail” safety choice, or mainly for simplicity?

Would you have any concerns if we validated no-op by parsing terraform show -json or terraform plan -output json and confirming there are no resource actions (create/delete/replace), while ignoring .output_changes?

Thanks!

[minamijoyo]

First, it should be noted that changes to the root module output actually affect the contents of tfstate and may indirectly affect downstream consumers (terraform_remote_state). Therefore, terraform plan treats this as a change.

One possibility is to refine the return value of terraform plan -detailed-exitcode, but this would not be easy in the short term due to the Terraform v1.x compatibility promise.

As a short-term workaround, enabling the force flag in the migration block of tfmigrate allows you to ignore plan changes. Still, the plan changes will not converge unless you explicitly execute terraform apply after tfmigrate apply.

The plan file generated internally by tfmigrate has a different lineage from the original tfstate, so it cannot be applied as is. Of course, you could create a script that parses the plan file and executes terraform apply if it only contains output, but this goes beyond the scope of tfmigrate's responsibilities.

Another point worth mentioning is that if you are going to parse the plan file, you might consider adding an ignore_changes option to the migration block to specify what should be ignored clearly. This feature itself is helpful, but it does not change the fact that terraform apply is still required after tfmigrate apply. Since no exclusive lock is taken, you must confirm that the changes are only outputs before running terraform apply.

[minamijoyo]

I found an existing feature request to ignore output changes. This duplicates #105.

[axon-zzhu]

thanks, let me double check.

[minamijoyo]

Just to be clear, the force flag has already been implemented, but the ignore_changes flag has not yet been implemented. This is a hypothetical discussion based on the assumption that if a flag to ignore output is to be added, a more general mechanism would be preferable.

[axon-zzhu]

yes, thanks. for us, using force to proceed despite diffs is too coarse/risky. We are discussing how to implement the ignore_changes flag.