Will Yardley

I see this with the non-beta google provider as well, I think. e.g., https://registry.terraform.io/providers/hashicorp/google/3.90.1/docs/resources/service_account, which is a 404, vs., say, https://registry.terraform.io/providers/hashicorp/google/3.90.1/docs/resources/google_service_account There are also some cases where the doc link...

I'm noticing this as well, with either non-indented or indented heredocs (`

> I ask because my understanding of Renovate is that its purpose is to automatically propose upgrading to newer versions of a dependency, and for Terraform in particular I would've...

> I guess my ideal model of how Renovate should behave with Terraform is to only update the lock file, and to propose selecting the highest-precedence provider version (per semver...

> Here's an question that might shed light on what I'm missing here: if Renovate hypothetically already had perfect support for updating the lock file as I described earlier, and...

> So far having exact version constraints in your modules feels functionally equivalent to having exact versions tracked in the lock file, but I assume there must be some detail...

ps - I will try this out (checked in lockfiles w/ Renovate) with a small personal project and see how the current state is in terms of how it's working.

So, the good news is that Renovate does deal with multiple lockfiles Ok, and it basically works, though the hash format seems different from what I generated locally [side note:...

ps - If I init based on the lockfile Renovate proposes locally, it also changes the lockfile back as shown (maybe related to #27811; also related: https://github.com/renovatebot/renovate/discussions/11821): ```diff diff --git...

ps: https://github.com/renovatebot/renovate/issues/13692 is also well worth reading, and has some explanation / discussion on why they implement the lockfile update in code vs. using the terraform binary. For one thing,...