New tool to detect outdated versions // and update GitHub managed ones

[fulldecent]

Summary

I used data from the check-outdateds-actions for the research to do this work.

This pull request carefully bumps the version of official CI GitHub Actions to a newer or latest version.

This helps everyone because it will make it easier for us all to use the new runners when available. And it will help us see the new GitHub Actions and their features, rather than starting out a few versions behind.

• ✅ If the new or latest version supports the same syntax as the current usage, then the upgrade is in scope for this PR.
• ✅ If this repo currently pins a version because it wants a specific feature, but that was later introduced in a public maintained release of the updated action then updating that action is in scope for this PR.
• ❌ Any changes that require major refactoring because of changes in a GitHub Action are out of scope for this PR. But we should do that work later as a separate initiative. (I have not identified any specific cases of this.)
• ❌ Any changes to action versions other than actions/... are OUT of scope for this PR.
• ⚠️ Any formatting changes are out of scope of this PR. If I was already touching some part I may have fix formatting in just that part. But if this is unwelcome please tell me or send a recommendation commit and I can pull that in.

---

Pre-requisites

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

^^ Not applicable. This is not a new workflow.

---

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.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[fulldecent]

I have fixed the merge conflicts with the main branch and this is now clean again to merge

[ScottBrenner]

Suggested change

	- uses: actions/checkout@v5
	- uses: actions/checkout@v6

[fulldecent]

I agree.

At the moment I'm having trouble adding that update (across all occurrances) this this PR.

If anybody would commit access on this revoke can push that commit to my PR I would appreciate it