Automate Terraform Platform Detection for Lockfile Hashes #4905
Conversation
Needs refactor and tests
Still needs refactor and tests
Nishnha
changed the title
Change the order in which we look for platforms to be the most common to the least common Optimized regex to grab the h1 hashes only
Nishnha
force-pushed
the
nishnha/automate-terraform-hashes
branch
from
392375e
to
a8aeac1
Compare
Currently failing test since we exit early before we do the comparisons...
The h1 provider hashes in a lockfile can be used to look up architecure the provider is built for. We do this by running `terraform provider lock` with a `-platform=` which could be linux_amd64, darin_amd64, etc. We compare the hash we get from those platforms to the one we see in the original lockfile. If they match then we know the user who checked in this lockfile was using that architecture. We stop chekcing platforms early if we determine that all of the h1 hashes in the original lockfile are accounted for. When we go to actually update the lockfile, we can download the provider hashes for all the necessary architectures in one go by chaining multiple `-platform=` flags. We also sort the hashes in an order that we assume is the most to least common.
| [content, provider_source, declaration_regex] | ||
| end | ||
|
|
||
| def lookup_hash_architecture # rubocop:disable Metrics/AbcSize, Metrics/MethodLength, Metrics/PerceivedComplexity |
There was a problem hiding this comment.
Whew that's a big one 😄 are there maybe any methods that we can extract out of here to make this a little easier to grok? Happy to take a stab at it (tomorrow) also
There was a problem hiding this comment.
Overall the change looks good to me, I think it might be worth trying to extract some logic from #lookup_hash_architecture, rubocop also complains about this and we need to disable 3 linting rules in order to satisfy it, but don't want to block on it. We can either tackle it in this PR or follow up later, lmk if I can help with this!
Thanks for the review! 🎉 I think it would be best for the community to get this fix merged in since it seems better than the status quo described in #4784 I decided to open #5013 as a refactor pass on this PR. Maybe we can pair up on it together sometime this week? |
|
This PR was shipped in #5014 |
|
This has instantly removed the need for the action, and made it immediately do exactly the right thing for virtually everyone using Terraform - thank you for getting this sorted :) |
|
Just to gently flag, it seems like this has stopped working... not quite sure why
|
|
We had a brief period where we had to roll back this PR. Sorry about that! |
|
Thank you very much for this! It enabled us to finally start using dependabot for our terraform dependencies ❤️ |
Terraform supports a few different architectures and, depending on the one(s) being used in the project, will save a hash for each in the
.terraform.lock.hcllockfile.Previously, Dependabot would use the default architecture
linux_amd64for every Terraform update, which caused issues for users who were not using that platform (see #4784).This PR automates Terraform architecture detection by comparing the existing lockfile hashes against the possible platforms. Once the architecture(s) are determined, Dependabot will update the hashes for the actual architectures in that project to the new version.
The architectures that we check are (in order):