gh-146488: hash-pin all action references

[woodruffw]

See #146488.

What I've done here is run zizmor --fix=all ., and then cross-checked the fixes with pinact run -v .github/workflows/*.yml.

CC @sethmlarson

• Issue: CI: Hash-pin all actions #146488

[sethmlarson]

LGTM

[woodruffw]

Sorry for the commit noise here, I fixed two lingering subpath mistakes (I'm pretty sure these are a bug in zizmor's --fix; I'll triage that separately.)

[hugovk]

Question about Dependabot.

Before, we just used major versions, like actions/checkout@v6. Dependabot would only update us to `v7, not minor or patch bumps.

Now, we pin to an exact commit, actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2, which of course maps to an exact x.y.z.

Does this mean Dependabot will now update us to 6.0.3, or 6.1.1, or whatever is available when it next triggers? This means more notifications. Is this the preferred way?

Or can we configure it to only trigger when there's a major bump?

[sethmlarson]

@hugovk Dependabot can be configured to only update on major versions, I don't think having the pin set at a minor/patch would change that policy if it's defined already in dependabot.yml? Because I do know that Dependabot will ignore your policy completely if there's a security vulnerability associated with an action, leading to a patch/minor release getting used.

[zware]

I'm afraid this is going to be a bit churny, but I think it's worth trying out. Hopefully the churn fears are overblown, or can be configured around :)

[hugovk]

@hugovk Dependabot can be configured to only update on major versions, I don't think having the pin set at a minor/patch would change that policy if it's defined already in dependabot.yml? Because I do know that Dependabot will ignore your policy completely if there's a security vulnerability associated with an action, leading to a patch/minor release getting used.

OK, thanks. I guess we'll be getting a PR once a month anyway, so they might as well update to the latest x.y.z.

I'm afraid this is going to be a bit churny, but I think it's worth trying out. Hopefully the churn fears are overblown, or can be configured around :)

monthly used to be the longest interval, but Dependabot has fairly recently added more options: quarterly, semiannually, yearly and cron:

https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#interval

Shall we try quarterly?

[webknjaz]

Shall we try quarterly?

Personally, I only use quarterly in pre-commit.ci since it doesn't support higher values. For dependabot I'd go for a longer period. I think that the security updates disregard that setting so that should be fine.