IBX-11778: Updated GitHub Actions to latest versions

[alongosz]

🎫 Issue	IBX-11778

Related PRs:

• IBX-11778: Updated deprecated GitHub Actions in tag-triggered workflows commerce-skeleton#11

Description:

Bumped all uses: action references in .github/workflows/ to their latest versions, and standardized runs-on: to ubuntu-26.04 (the current standard derived from the ibexa/bundle-generator ibexa-oss skeleton).

Most bumps are MAJOR version jumps (repos hadn't been touched in a while):

• actions/checkout v3/v4 → v7
• actions/setup-python v3/v5 → v7
• stefanzweifel/git-auto-commit-action v4 → v7
• DavidAnson/markdownlint-cli2-action v20 → v24
• vale-cli/vale-action v2 → v3
• actions/create-github-app-token v2 → v3
• actions/upload-artifact v4 → v7
• peter-evans/find-comment v3 → v4
• actions/github-script v6 → v9
• peter-evans/create-or-update-comment v4 → v5
• actions/setup-node v4 → v7
• peter-evans/create-pull-request v7 → v8
• actions/cache v4 → v6

Pin styles were preserved, not changed:

• ramsey/composer-install and marocchino/sticky-pull-request-comment are pinned to version branches (v3/v2 → v4/v3) in most files — kept as branch pins per that convention.
• ramsey/composer-install in release_composer_package.yaml is SHA-pinned separately — bumped the SHA to the 4.0.0 tag, kept the SHA-pin style.
• shivammathur/setup-php (SHA pin) and lycheeverse/lychee-action (SHA pin) were already current, no change.
• ibexa/gh-workflows/...@main (reviewers.yaml) is a deliberate trunk-tracking pin, left untouched.

For QA:

No functional changes expected; this only bumps CI tooling versions and the runner image.

Documentation:

Review

🤖 Generated with Claude Code

[github-actions]

Preview of modified files: no change to preview.

[github-actions]

Summary

Status	Count
🔍 Total	750725
🔗 Unique	15057
✅ Successful	6306
⏳ Timeouts	1
🔀 Redirected	2
👻 Excluded	744418
❓ Unknown	0
🚫 Errors	0
⛔ Unsupported	0

Timeouts per input

Timeouts in site/content_management/field_types/type_and_value/index.html

• [TIMEOUT] https://martinfowler.com/eaaCatalog/registry.html (at 14641:77) | Request timed out

Redirects per input

Redirects in site/ai/ai_actions/configure_ai_actions/index.html

• https://platform.claude.com/docs/en/about-claude/models/overview --[307]--> https://platform.claude.com/docs/en/models/overview

Full Github Actions output

[mnocon]

I guess you're doing it for other repos as well, and it would make sense to have a consistent approach for all Engineering repos - we're ignoring the Use full commit SHA hash for this dependency. advice?

[alongosz]

I guess you're doing it for other repos as well, and it would make sense to have a consistent approach for all Engineering repos - we're ignoring the Use full commit SHA hash for this dependency. advice?

@mnocon my rules are:

1. if repo used commit SHA, use commit SHA
2. if it's actions/* GHA, use @v notation (doesn't matter if it's tag or branch)
3. if it's ibexa/* GHA feel free to use @main, it's safe
4. if it's anything else, use commit SHA

Here 4) got intentionally violated, keeping rather your convention, to avoid confusing y'all and producing maintenance cost.
BUT if you prefer SHAs everwhere, it's easy to change.

I'm not going to do SHA everywhere for all other packages, because it's a huge maintenance cost. Every time a bug-fix comes out for that action, it requires updating. For instance GHSA-5wxr-w449-57cm on shivammathur/setup-php - fixed in v2.37.1. @v2 "floating" tag satisfies that fix without touching repos using it. Using SHA everywhere instead requires to update all workflows using this action in all repos.

It's not an ideal situation because malicious actor can force-push a tag, especially a floating one. For that reason gh-workflows will use SHA pinning instead of tags or branches for all non-ibexa actions. If it's in one place, it's manageable.

If we find good way to bulk update these, with Claude, then we might change the approach and use SHA everywhere. Or explicit tag, as long as action maintainer enabled immutable releases.

@mnocon do you want me to switch here to SHAs? It could be one of the exceptional packages, along with gh-workflows and AFAIR archive-maker too, actually.

[mnocon]

@alongosz Thank you for the explanation, I think it's fine - we can always revisit this in the future if needed.

Ok for me to merge this, please let me know (here or on Slack) if you want to handle the cherry-pick yourself (to the following branches: 4.6, 6.0, saas) or I should do this (I'm fine with both options)