this bug is also mentioned on issue #848 however that ticket is closed and there doesn't seem to be any fix or workaround in sight.

there's also a good suggestion here: #454 (comment)

This is actually not recommended to do, and in fact, is impossible due to terraform limitations (you can't have a plan that spans multiple state files). See #1127 (comment) for additional commentary on the -all commands.

For plan-all, I forgot to mention that we want to solve this eventually, but currently we need a few more design cycles to come up with a proper solution.

As far as fixing the specific error with the forced args, we could certainly get that fixed, but it doesn't resolve the fundamental issue with using reviewed plans on apply-all (which is an anti-pattern).

For plan-all, I forgot to mention that we want to solve this eventually, but currently we need a few more design cycles to come up with a proper solution.

As far as fixing the specific error with the forced args, we could certainly get that fixed, but it doesn't resolve the fundamental issue with using reviewed plans on apply-all (which is an anti-pattern).

Hello,

It's not anti-pattern. I am not suggesting to use one single plan to apply.
Check out the code below. All works except this issue with -input=false and -auto-approve forcibly added at the end of the generated command.

terraform {
  before_hook "generate_plan_path" {
    commands     = ["plan"]
    execute      = ["mkdir", "-p", "${get_parent_terragrunt_dir()}/plans/${path_relative_to_include()}"]
  }

  extra_arguments "plan_args" {
    commands = [
      "plan"
    ]

    arguments = [
      "-out", 
      "${get_parent_terragrunt_dir()}/plans/${path_relative_to_include()}/tf.p"
    ]
  }
  
  extra_arguments "apply_args" {
    commands = [
      "apply"
    ]

    arguments = [
      "${get_parent_terragrunt_dir()}/plans/${path_relative_to_include()}/tf.p",
    ]
  }
}

To clarify, we (Gruntwork) consider it an antipattern to use plan-all => apply-all on a day to day basis, because plan-all is fundamentally broken right now when you have cross module dependencies. If you have no cross module dependencies, then, yes plan-all works, but I suspect most sufficiently complex deployments will have cross module dependencies.

All I was trying to say is that there is much more than just having the single module plan files work with extra_arguments if you want the actual experience of using plan files with xxx-all commands.

In any case, as mentioned above, a PR to fix this particular issue with injected args is certainly welcome. I think this could be fixed by updating the logic in this function to look for positional args in argsToInsert and insert them at the end.

@yorinasub17 I think i understand what you mean now. It was a bit confusing. So apply-all doesn't actually run apply on plans shown when you do plan-all (because of mocked resources) but instead it re-runs the plan right before applying.
I didn't look at the code, I am just guessing here.
It's sad, because it would make so much sense. At least to have some way of getting the dependency graph and based on that to configure the CI with automatic sequential plan and apply on specific resources.

So apply-all doesn't actually run apply on plans shown when you do plan-all (because of mocked resources) but instead it re-runs the plan right before applying.

Yup this is basically correct. apply-all works because it runs the apply in dependency order, so the upstream module changes are reflected by the time the downstream module apply happens. When you introduce plan files, this all breaks down, especially if you are using mock outputs, since the downstream plan will be based on garbage input.

Just bumping this one.

I'm currently trying to make a CI pipeline using terragrunt and I'm running into this as well.

The workflow I had in mind was:

1. Make a PR with changes to multiple modules
2. CI generates plans using terragrunt plan-all and storing the plan in each module folder.
3. CI filters the plans to only those with changes and without parent dependencies with changes.
4. User verifies plan outputs and makes a PR comment "Apply all (perhaps with a hash representing a set of plans to apply)
5. CI runs terragrunt apply-all with a --terragrunt-include-dir {} for each plan, thus restricting the plans being applied. Extra Args will also be used like above to run terraform apply with a plan for each module.
6. Repeat 2-5 until nothing else is planned and everything is applied.

Currently this isn't possible because specifying a plan with terragrunt apply-all does not work.