ci(v3): update GitHub actions and review workflow triggers

[galargh]

• Because this PR includes a bug fix, relevant tests have been included.
• Because this PR includes a new feature, the change was previously discussed on an Issue or with someone from the team.
• I didn't do anything of this.

---

This PR is a subset of #5301 and, unlike the original, it targets the v-next branch.

In this PR, I update GitHub actions to the latest versions. I reviewed the changelogs to ensure there are no breaking changes announcements that would affect us.

I also reviewed the workflow triggers to ensure we don't use invalid syntax (e.g. $default-branch) and that we use them consistently.

I will propose improvements to the caching setup and work deduplication in separate PRs to minimise the diffs.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
hardhat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 2, 2024 11:16am

[changeset-bot]

⚠️ No Changeset found

Latest commit: d0a047a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[galargh]

1. I see the E2E tests currently do not pass against the v-next branch. Should I restore the filter that runs them only on pull requests to main?
2. Would the expected flow for changes like this one be to first merge them into v-next and then cherry-pick applicable subset onto main?

[alcuadrado]

1. I see the E2E tests currently do not pass against the v-next branch. Should I restore the filter that runs them only on pull requests to main?

Yes, we don't expect the e2e tests to run on v-next, as they aren't relevant, and they are quite slow.

2. Would the expected flow for changes like this one be to first merge them into v-next and then cherry-pick applicable subset onto main?

I think for this kind of change, this makes sense. We don't have many of situations like this, luckily.

[alcuadrado]

2. Would the expected flow for changes like this one be to first merge them into v-next and then cherry-pick applicable subset onto main?

I think for this kind of change, this makes sense. We don't have many of situations like this, luckily.

Actually, after looking at your other PRs, I'd say that it depends on what we are targeting. If the change is meant to go to main, I'd do a PR into main.

We periodically merge main into v-next.

[galargh]

2. Would the expected flow for changes like this one be to first merge them into v-next and then cherry-pick applicable subset onto main?

I think for this kind of change, this makes sense. We don't have many of situations like this, luckily.

Actually, after looking at your other PRs, I'd say that it depends on what we are targeting. If the change is meant to go to main, I'd do a PR into main.

We periodically merge main into v-next.

That's fantastic! In that case, I split this PR into this one which targets v-next and only modifies v-next-* workflows and #5566 which does the same job of updating actions versions and triggers but for the v2 packages and targets main. I followed the same approach with other ci PRs too.

1. I see the E2E tests currently do not pass against the v-next branch. Should I restore the filter that runs them only on pull requests to main?

Yes, we don't expect the e2e tests to run on v-next, as they aren't relevant, and they are quite slow.

Thanks! I restored the branches filter for the pull_request trigger of the e2e tests workflow in #5566