figure out a way to support commit refs for our github action

[motatoes]

based on #1930 it would be great for digger to support referecing the action using diggerhq/digger@abc12343313 however the blocker for this is that we currently do a very basic check and see if a reference starts with letter "v" then we download from the release otherwise we clone and build. So doing it in this way would lead to building each time unless it starts with a "v" then it would lead to an error downloading.

We need a smarter way to acheive release commit pulling. Open questions:

• Is there a way to fetch release name based on commit sha?
• Is there a way to tie binary artefacts to a commit rather than a release?
• Can we generate binaries on the fly and tie them to a commit on the main branch rather than to a release? for example maybe we can start uploading binaries and sha sums to s3 rather than github and link them to commit artefacts so the check could instead be: if url exists then download and run otherwise clone and build something like that would work

[dannysauer]

I recently learned that Mend Renovate can handle automating this (and, of course, also started doing that in my repos).
https://docs.renovatebot.com/modules/manager/github-actions/#digest-pinning-and-updating
The summary is that the tag is recorded as a comment so updates can still happen automatically without the risk of a tag being modified.

It's still possible for a compromised repository to publish a new versions tag which will trigger an update, of course. But the only way to protect against that is to require that commits always be signed with a trusted person's key, etc. But what if the developer's machine is compromised, etc. ;)

TLDR: I suggest using Renovate to generate the updates, and then use organization-appropriate code review processes before merging PRs.

[dannysauer]

There is, of course, Ratchet as well. But Renovate can also update Ratchet. ;)