Checkout: Update all workflows to use Checkout V4

[jsoref]

Workflows should be using checkout v4 (roughly https://github.com/actions/checkout/releases/tag/v4.0.0, plus later updates). It doesn't have breaking changes. A bunch of workflows in this repository are already using it. There's no reason to inconsistently use v3/v4.

Apparently I missed a couple in #2270

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.
• Should specify least privileged permissions for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • creator: Name of the organization/user producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[reactive-firewall]

🚧 This will conflict with the changes of PR #2497 which includes this same change. If this change is accepted on this PR, please coordinate with PR #2497 (author willing to rebase if this is accepted first)

[jsoref]

Often such changes won't trigger conflicts as long as the changes are identical.

[reactive-firewall]

I'll go ahead and mark this resolved. 🔰 Sorry for the confusion.

TL;DR:

---

🙊 unfortunately my changes move this line while changing it so I was worried about it.

🩹 Luckily when I tested it locally there was no issue here (when merging yours before mine, only an unrelated rebase was needed)

Script used to test and confirm:

cd /tmp
git clone https://github.com/actions/starter-workflows.git
cd ./starter-workflows
# add your fork from PR 2465
git remote add -t bump-actions -m main jsoref https://github.com/jsoref/starter-workflows.git
# add my fork from PR 2497
git remote add -t patch-1 -m main reactive-firewall https://github.com/reactive-firewall/starter-workflows.git
# fetch local copies of the forks
git fetch --all
checkout bump-actions
checkout patch-1
checkout main
# rebase fork from PR 2465 (and resolve with mains copy)
git rebase main bump-actions
git checkout main -- deployments/google-cloudrun-docker.yml  # this is not modified in my PR so exact resolution does not matter 
git checkout main -- deployments/google-cloudrun-source.yml  # this is not modified in my PR so exact resolution does not matter 
git rebase --continue
# make sure we are on main (the target branch of both PRs)
git checkout main
git merge bump-actions main  # works now with rebase
git merge patch-1 main  # no conflict in code-scanning/bandit.yml :tada:

[jsoref]

No worries and thanks for testing. I know that sometimes it works but didn't have the energy to do the testing myself.

It mostly doesn't matter, I'm very comfortable rebasing such changes and wouldn't mind doing so if someone from github said that they were ready to actually look at the PR and that it had conflicts.

[jsoref]

@alexisabril is there a chance of someone looking this anytime soon?