Lock GitHub Actions dependencies to SHAs for security and predictability

[larouxn]

What is this PR doing?

Locks the three GitHub Actions dependencies to specific versions via said versions' SHAs.

Why is this PR doing such?

1. Locking to SHAs is best practice for security and sanity as we know which version is being used. Without doing Actions will simply use whatever latest version is available, a silent bump of sorts. For example, actions/checkout just released a v4.3.0 today, which will be used automatically.
   2. With locking to SHAs we should receive (albeit somewhat rare) Dependabot upgrade PRs for said Actions dependencies which version is in use will be explicit and thus can be updated explicitly. For example, actions/checkout v5.0.0 was just released today. After this PR I expect we'll receive a bump PR to such. We should receive bumps even without locking but such would only be for major versions. Actions would use latest version for a given major versions per run thus minor and patch versions automatically bump transiently.

Reference

• https://github.com/actions/checkout/releases/tag/v4.3.0
• https://github.com/ruby/setup-ruby/releases/tag/v1.255.0
• https://github.com/actions/stale/releases/tag/v9.1.0

[etiennebarrie]

We very rarely had issues with GitHub Actions, the only one I can find is 9a4e23e and it was an issue of a workflow we weren't directly using.
In addition to the regular dependency update fatigue, shouldn't it also lead us to upgrade to potentially less stable versions than the releases? Can we somehow get the best of both worlds? It seems we can't.

I guess it's not ideal but it probably makes sense to do it anyway, we have few of them and they don't update all that often (ruby/setup-ruby is the most active). Thanks for your contribution.

Actually looking more into it, there is already a concept of immutable action package: https://github.com/Shopify/maintenance_tasks/actions/runs/16751139569/job/47421412230#step:1:28
But I tried and @v4 by itself is not immutable, we did get v4.3.0 in this workflow run.
So maybe we could keep the tags for these two? And it seems we would get the upside of only using released versions while ensuring they also don't change. Maybe? The guarantees don't seem strong, so I'm tempted to just merge your PR as is.

[larouxn]

In addition to the regular dependency update fatigue, shouldn't it also lead us to upgrade to potentially less stable versions than the releases? Can we somehow get the best of both worlds? It seems we can't.

I guess it's not ideal but it probably makes sense to do it anyway, we have few of them and they don't update all that often (ruby/setup-ruby is the most active). Thanks for your contribution.

Definitely a concern, having more upgrade PRs to merge. That said, as you mentioned, of the three packages setup-ruby is more-or-less the only one with any sort of frequent updates.

• setup-ruby has had quite a few updates in the last couple months though mostly we can expect bumps every 2 months re: new Ruby versions being released (Ruby release schedule noted)
• actions/checkout just had its first two releases (v4.3.0 and v5.0.0) since Oct 2024 (+9 months)
• actions/stale's last update was this past January (~9 months ago) and the release prior to that was in December 2023, over year prior to the most recent release

Thus, I think (am hoping) this won't generate too much noise/toil. I suppose our one recourse could be to drop the setup-ruby SHA-ification as its releases typically just add functionality for new Ruby releases and rarely make any breaking changes. The other two have a higher (albeit minor) chance of breaking something.

If you'd like me to drop the setup-ruby change I can. Glad to merge either way.

---

Speaking of GitHub Actions Dependabot, I was surprised to see that Dependabot found the actions/checkout v4 -> v5 upgrade and said it created a bump PR but it did not create a PR. Didn't even create a branch. It showed up eventually.

• Bump actions/checkout from 4 to 5 #1263

---

EDIT: Pushed commit up again with refined message as to not be inaccurate. 🙏