» Spacelift answer
Thanks for your patience! the issue is that when Spacelift serves a module via tfr://, it uses GitHub's auto-generated tarballs, which don't include git submodule content. That's why the terraform-aws-apigateway-v2 directory is empty, and why git::ssh:// works fine (it does a real git clone).
Unfortunately git submodules aren't supported via the module registry right now. Your best options are:
Stick with git::ssh:// for this module
Copy the submodule content directly into your repo
it's not on the roadmap as far as I know. Feel free to raise it at https://feedback.spacelift.io so the team can track interest.
» My answer
Is it planned to be implemented? I didn’t want to include submodule content in my repo as it would clutter things and also will be hard to update the submodule after. I wanted to have clear line between my repo and the submodule repo.
» Spacelift answer
Given you want to keep a clean separation, the best workaround at this point would be publishing terraform-aws-apigateway-v2 as its own module in the Spacelift registry and referencing it as a separate source instead of a git submodule.
» My answer
Yes but this is rather workaround, because then I need to update my fork, publish new spacelift module version and then update my terraform-apigw-v2 module and second time publish another version. With submodules I update with git submodule -q foreach git pull -q origin master and publish version terraform-apigw-v2. So it is one step less. I also try to avoid nested dependencies on our modules as it already proved to be time consuming and bad practice. Dependency on external module didn’t cause us trouble yet.