Remote(s) data source within a TF module

[Levistator]

Hey, I am working on a TF module that will be used within other projects.

I want to use the remote(s) datasource as a way to get the URL of the project that is calling the module.

The other projects have various locations that their terrafom lives at so I can't just hardcode a ../ solution.
with directory as path.root it fails reporting Could not open git repository [.] because of: repository does not exist

Do you have any ideas? I was hoping it would work how the git CLI does when calling git config --get remote.origin.url

[my_module] = {
metio/git

• data "git_remote" "repo"
  }

[my_project] = {
my_module
}

[sebhoss]

Hi, can you try to use https://developer.hashicorp.com/terraform/language/functions/abspath ? The provider kinda works like the CLI (but uses a different git implementation), however it needs a directory to work from and the name of the remote (origin in your case).

So something like this might work:

data "git_remote" "remote" {
  directory = abspath(path.root)
  name      = "origin"
}

[Levistator]

Dang, I was really hoping it was that easy 😭 🤣

After poking at it, it appears that it doesn't really matter whether the directory value is relative or not but it needs to be pointed at the root of the my_project repository.

in my case

my_project/
  infra/
    main.tf

And directory needs to be pointed at the root.

I have a feeling this is more related to how go-git is performing it's git operations as opposed to an incorrect implementation on your end?

[sebhoss]

Ok yeah I see. One potential solution right now might be to expose an input variable in your infra module that expects the path of the parent module. Each consumer of your module then needs to specify the root directory which they can get with path.root or the absolute value of that. You might even be able to define a default value for that variable with a value of abspath(path.root) or similar but I'm not sure when/how Terraform evaluates these path based values in this context and I can't test it myself because I'm currently moving to another city and thus not in front of a computer 😬

In order to get rid of the variable altogether, this provider would have to mirror the behavior of the git cli and check parent folders when opening repositories. This should be doable without a change in go-git and I think that it would be a nice addition to this provider. I'll take a deeper look on the weekend!

[Levistator]

Oof moving sucks, good luck!

I'll poke a bit more but let me know if/when you figure anything out!

[Levistator]

I don't think there is a good way to do this automatically from just within the TF hcl.

I did have a thought on implementation, I feel like it shouldn't always do the recursive upwards search. Maybe only if the directory is .?

I was trying to avoid any obvious vulnerabilities lol

[sebhoss]

Ok I think I found something nice - go-git already has a DetectDotGit option which can be enabled. However it fails when bare repositories are used. I enabled support for bare repositories a while back but I'm not sure if anyone is actually using it. So I wrote a little weird workaround and it seems to work fine - I'll merge once the tests pass! A new release is happening automatically next friday but I could push it manually if you need it now ^^