3 ms·

There is a breakdown in UX if your references need to look like this SHA `11bd71901bbe5b1630ceea73d27597364c9af683` That means absolutely nothing to a human b

There is a breakdown in UX if your references need to look like this SHA `11bd71901bbe5b1630ceea73d27597364c9af683` That means absolutely nothing to a human being Whereas > hashicorp/setup-terraform@v3 Is easy to understand. How about > hashicorp/setup-terraform!v3.0.1 This version, and only this version, fails if the version cannot be found. Or > hashicorp/setup-terraform@v3-2025-03-26-15-01 Give me the version of the library as it was at this specific time or fail if it can't be found Presumably it would be wise to check the SHA as well to ensure no changes have taken place maliciously One could go old school and import the code from the various needed libraries, into the main project. Now you have complete control over what runs and it can be audited and will be in a safe state until explicit action is taken to update the code.

junon 2y ago
This is rehashing (no pun intended) a very long-discussed issue about versioning. Your post also contradicts itself. > SHA `11bd71901bbe5b1630ceea73d27597364c9af683` - That means absolutely nothing to a human being > Presumably it would be wise to check the SHA as well to ensure no changes have taken place maliciously That's exactly why the first one happens so often - I've checked the dependency at that version, and I want to make sure I only get that version, as spoofing sha's in a Git context is not part of my threat model.
- ThinkBeat 2y ago
  That is true. In the post I am replying to the idea was SHA `11bd71901bbe5b1630ceea73d27597364c9af683 as what the script contains as a reference. While i would advocate hashicorp/setup-terraform@v3-2025-03-26-15-01 Hash: `11bd71901bbe5b1630ceea73d27597364c9af683` I consider it easier to deal with, .