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.

[sethmlarson]

Thanks for the reviews, everyone!

[hugovk]

How far should we backport this? Probably all the way back to 3.10?

[sethmlarson]

We should probably backport all the way to 3.10.

[miss-islington-app]

Thanks @woodruffw for the PR, and @sethmlarson for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @woodruffw and @sethmlarson, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker a504c0a590b9379688e4718225efb361b94cc4a1 3.14

[woodruffw]

I took a look at these automatic backports and they're going to be pretty gnarly because of actions drift between versions -- I think the easier thing to do here is just create from-scratch PRs for each living branch. I'll work on that + track in the issue.

[bedevere-app]

GH-147978 is a backport of this pull request to the 3.10 branch.

[bedevere-app]

GH-147979 is a backport of this pull request to the 3.11 branch.

[bedevere-app]

GH-147980 is a backport of this pull request to the 3.12 branch.

[bedevere-app]

GH-147981 is a backport of this pull request to the 3.13 branch.

[bedevere-app]

GH-147982 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-147983 is a backport of this pull request to the 3.14 branch.