[TASK] Update and SHA-pin all GitHub Actions

[CybotTM]

Summary

Updates all GitHub Actions across 7 workflow files to their latest versions and pins every action to its exact commit SHA for supply chain security.

Version updates

Action	Old	New	SHA
actions/checkout	v4	v6.0.2	de0fac2e
ramsey/composer-install	v2	3.1.1	3cf229dc
docker/setup-buildx-action	v2	v3.12.0	8d2750c6
actions/upload-artifact	v4	v6.0.0	b7c566a7
actions/download-artifact	v4	v7.0.0	37930b1c
actions/cache	v4	v5.0.3	cdf6c1fa
dependabot/fetch-metadata	v1/SHA	v2.5.0	21025c70
frankdejonge/use-github-token	1.0.2	1.1.0	15e6289d
frankdejonge/use-subsplit-publish	1.0.0	1.1.0	00010151

Major version changes

In general these updates update used node to 20/24.
Also includes two additional fixes which do not affect render-guides as far as I can tell.
The breaking changes are the raised requirement for gitlab runners - which would only affect the project if it uses self-maintained runners.

• https://github.com/actions/checkout/releases/tag/v5.0.0
  • add/support node 24
• https://github.com/actions/checkout/releases/tag/v6.0.0
  • "Updated persist-credentials to store the credentials under $RUNNER_TEMP instead of directly in the local git config."
• https://github.com/actions/upload-artifact/releases/tag/v5.0.0
  • add/support node 24
• https://github.com/actions/upload-artifact/releases/tag/v6.0.0
  • changing default to node 24
• https://github.com/actions/download-artifact/releases/tag/v5.0.0
  • This release fixes an inconsistency in path behavior for single artifact downloads by ID. If you're downloading single artifacts by ID, the output path may change."
  • As far as I can tell, render-guides is not affected by this
• https://github.com/actions/download-artifact/releases/tag/v6.0.0
  • add/support node 24
• https://github.com/actions/download-artifact/releases/tag/v7.0.0
  • changing default to node 24
• https://github.com/actions/cache/releases/tag/v5.0.0
  • now uses node 24
• https://github.com/ramsey/composer-install/releases/tag/v3.0.0
  • actions/cache upgraded to v4 (node to 20)
• https://github.com/dependabot/fetch-metadata/releases/tag/v2.0.0
  • upgrade node 16 to 20
• https://github.com/docker/setup-buildx-action/releases/tag/v3.0.0
  • node 20 now default

Additional SHA-pinned actions (already at latest version)

Action	Version	SHA
shivammathur/setup-php	v2.36.0	44454db4
docker/metadata-action	v5.10.0	c299e40c
docker/login-action	v3.7.0	c94ce9fb
docker/setup-qemu-action	v3.7.0	c7c53464
docker/build-push-action	v6.19.2	10e90e36

Files changed

• .github/workflows/main.yaml — checkout, setup-php, composer-install
• .github/workflows/docker.yaml — checkout, buildx, qemu, login, metadata, build-push, upload/download-artifact
• .github/workflows/docker-test.yaml — checkout
• .github/workflows/deploy-azure-assets.yaml — checkout
• .github/workflows/split-repositories.yaml — checkout, cache, use-github-token, use-subsplit-publish
• .github/workflows/pr-auto-merge.yaml — fetch-metadata
• .github/workflows/pr-auto-approve.yaml — fetch-metadata

Test plan

• Main workflow (tests + quality + monorepo-validate) passes
• Docker build workflow syntax is valid
• Sub-split publishing workflow works
• Dependabot auto-merge/approve workflows trigger correctly

[linawolf]

The best course of action seems to be to merge this and try it out and watch the first runs of the pipelines.

I see less risk in hardening the versions but you made major upgrades to some versions so we would have to watch the pipelines closely. Best would be to merge this when no TYPO3 Core releases are planned that week so we dont have suddenly all the important manuals rendering.

[sbuerk]

Despite switching to commit hashes not discussing it for now, this pull-requests misses to provide a detail analysis and risk-assesment about raising marketplace action one or in some cases two major versions.

Actions following semver could introduce breaking things with new versions, dropping stuff and similar and possibile need adjustments. None of them is contained or mentioned in the pull-request nor the single commit messages.

Taken into account that this pull-request not only changes the version of official github provided actions, but also 3rd party market place actions this is would have to read that up.

Can you please provide a detailed risk-assesment about the raises and the analysis if there are changes or a statement about that it is okay with a reasoning for each of the updated action ?

Note

The list needs to be reviewable and easy verifiable, providing links
corresponding releases and/or upgrade information would be helpfull.

Important

DISCLAIMER Not part of the documentation team, above mentioned
statements are my personal view on this.

[CybotTM]

I am done with the PR, close it if it does not meet your ad-hoc requirements. I'm fine with rejecting this PR, would just be nice to have such requirements defined upfront not afterwards.

[CybotTM]

I added the major version changes, I skipped minor and bugfix, as these are already auto-merged currently.

[CybotTM]

Save CO² - update your node! ;-)

Waiting for your discussion to resolve

[linawolf]

To make review easie rand reduce scope, I would suggest to avoid mixing concerns and do the SHA pinning and Major version bumbs in separate PRs.

That way we can review the structural change (pinning) independently from the version upgrades.