Prevent terraform init from trying to download git submodules

[shellwhale]

Terraform Version

Terraform v1.7.4

Use Cases

I'm trying to init a module that has it's source code stored in a repository where there is a git submodule (that git submodule does not contain terraform code). I would like to tell terraform (or git) to not try to clone any submodules.

module "random_number" {
  source = "git::https://github.com/shellwhale/test-module.git//modules/random_number&depth=1"
  name               = "random_number"
}

Attempted Solutions

I tried shallow cloning with &depth=1 but it seems that the default behavior is to try to pull the submodules. I would like to avoid that.

From my understanding, by default, git clone doesn't pull the submodules. So I think there must be something in terraform's code that's enabling --recurse-submodules. I'm struggling to find that part of the code as I'm unfamiliar with the codebase.

MINIMAL EXAMPLE HERE : https://github.com/shellwhale/test-module/blob/main/global/main.tf
You can try it the above minimal example. I expect terraform NOT to clone the submodule located here https://github.com/shellwhale/test-module/tree/main/app/src

Proposal

No response

References

No response

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[apparentlymart]

Terraform implements git fetching using the upstream shared library go-getter, which currently fetches submodules unconditionally as part of its work.

Since that's a shared dependency with other software, and isn't maintained directly by the Terraform team, I think supporting this would require consensus with all of the other callers about whether and how to support it.

Unfortunately this particular library has become very resistant to change due to its high exposure to security-related concerns, and so adding additional options to it might not be desirable due to the overhead of maintaining yet another codepath in something that is already quite hard to maintain. I think to start we'll have to see if the maintainers are even comfortable with adding a new option for this. If the answer is yes, then we can think about how best to expose it. (Adding yet another random pseudo-query-string argument isn't ideal, but I don't really see any other way to specify it dynamically for a particular call. 🤷‍♂️ )