Fix remote repo panic

[JackFlukinger]

Hey @im2nguyen, this should resolve #84 . It just checks to make sure the module is not at a remote url before trying to load the module (for line number and file info).

[JackFlukinger]

Also, I removed the ecs-cluster example as I don't think the submodule was actually pointing to anything. If u want to re-add it, definitely do. Also, I added a nested-module example just for testing. It actually points back at this repo and uses the random-name module, but it won't work until you push these changes to main.

[im2nguyen]

Thanks!

It's interesting how this doesn't work on remote modules since rover uses the terraform plan output. The init command downloads remote modules and stores it in the .terraform dir, when you run a plan or an apply, it should use module in .terraform.

Even though this looks on a spot check, gonna verify the above before merging. (Aiming for Wed)

If I can't get to it by Wed, I'll just merge this as a stop gap 😄

[JackFlukinger]

Oh yeah @im2nguyen , line numbers and file names require tfconfig.LoadModule(dir), which can only load modules in the filesystem. I think we can probably remove the -tfConfigExists flag (after testing ofc), I think configuration existence is checked for automatically at this point.

To access line numbers and file names of nested modules, it essentially calls tfconfig.LoadModule(${parent-module-path}/${child-module-path}). Of course, with remote modules the source is usually something like git::https://github.com/im2nguyen/rover.git//example/random-test/random-name which can't be loaded.

I'll see if there's a way to parse the module call and access the module in the .terraform folder. If so, I'll commit it to this PR :).

[JackFlukinger]

Okay @im2nguyen , it feels a bit hackish but these commits directly parse the modules.json file in the .terraform folder. This file contains local module paths with which we use to load them for file names and line numbers.

I also removed the -tfConfigExists flag, since there's no longer any use for it. If the modules aren't available locally, rover just prints either Continuing without loading module from filesystem: ${module}. If the root module isn't available, rover prints

Could not load configuration from: ${workingDir}
Continuing without configuration file data...

Let me know if this seems like the right approach!

[im2nguyen]

This looks good! I ran into the following error while testing on the nested-test directory, but I assumed this was bc the main branch still references eks-cluster. It worked when I tested using another remote module though! 😄

$ ./rover -workingDir example/nested-test/
2022/01/24 10:33:45 Starting Rover...
2022/01/24 10:33:45 Initializing Terraform...
2022/01/24 10:33:55 Unable to parse Plan: Unable to initialize Terraform Plan: exit status 1

Error: Failed to download module

Could not download module "remote_module" (nested-module/main.tf:1) source
code from "git::https://github.com/im2nguyen/rover.git": error downloading
'https://github.com/im2nguyen/rover.git': /usr/local/bin/git exited with 128:
fatal: No url found for submodule path 'example/eks-cluster' in .gitmodules



Error: Failed to download module

Could not download module "remote_module" (nested-module/main.tf:1) source
code from "git::https://github.com/im2nguyen/rover.git": error downloading
'https://github.com/im2nguyen/rover.git': /usr/local/bin/git exited with 128:
fatal: No url found for submodule path 'example/eks-cluster' in .gitmodules

[im2nguyen]

Suggested change

[im2nguyen]

Suggested change