Refer to actions by commit hash #196
Conversation
raboof
force-pushed
the
refer-to-actions-by-hash
branch
2 times, most recently
from
bdb2f2f to
cc6a179
Compare
There was a problem hiding this comment.
I am in such an organization! ..and I've also been thinking about getting this into sbt-github-actions.
Regarding churn I'm not convinced it'd be a huge problem. Updates isn't currently automated by dependabot anyway, so the need to update dependencies by issuing PRs isn't really changed. But sure, it puts a strain on the reviewer who has to verify that the hash matches the intended version.
|
|
||
| object UseRef { | ||
| final case class Public(owner: String, repo: String, ref: String) extends UseRef | ||
| final case class Public(owner: String, repo: String, rev: String, ref: String) extends UseRef |
There was a problem hiding this comment.
Seeing as ref is now always rendered as a comment, I think it makes to keep ref as the actual reference used (be it a hash, tag, or branch name), and instead introduce comment: Option[String] = None. This way we'd retain source compatibility, also allowing users to opt-in to reference actions by a hash + comment, if they aren't already.
There was a problem hiding this comment.
I'm not sure - I think it's actually a feature that users would have to review the call site to make sure the third argument is a rev. I could see making the fourth parameter a comment: Option[String] though, no strong preference.
raboof
force-pushed
the
refer-to-actions-by-hash
branch
7 times, most recently
from
2453fa6 to
2f543bf
Compare
Some organizations have a policy of always referring to GitHub actions by commit hash rather than tag, as tags can be moved without review. This explores what this would look like for `sbt-github-actions`. Of course the main downside would be that updating the hashes creates churn.
raboof
force-pushed
the
refer-to-actions-by-hash
branch
from
2f543bf to
77948c4
Compare
| UseRef.Public("actions", "checkout", "v5"), | ||
| UseRef.Public( | ||
| "actions", | ||
| "checkout", | ||
| "08c6903cd8c0fde910a37f88322edcfb5dd907a8", | ||
| "v5.0.0"), |
There was a problem hiding this comment.
I'm sympathetic to having an immutable and repeatable CI configuration, but the downside to embedding git sha into *.scala code this way is that now the upgrade burden would shift to the sbt-github-actions maintainer and/or simply this would be left forgotten as the actions might ship fixes and patches.
There was a problem hiding this comment.
Jup - this PR was more of a 'straw man' to get the conversation going than something I'd expect to get merged in this form.
What would be the way forward here? Perhaps we could have an option that makes githubWorkflowCheck more lenient and allow dependabot to update versions (but not the rest of the workflow)?
There was a problem hiding this comment.
Given the limited number of upstream actions, we could probably run some weekly cron job that check them out and maintain a JSON file of action, version, and gitsha, maybe?
3 participants
Some organizations have a policy of always referring to GitHub actions by commit hash rather than tag, as tags can be moved without review.
This explores what this would look like for
sbt-github-actions. Of course the main downside would be that updating the hashes creates churn.