[TASK] Add reusable CI workflows for TYPO3-Documentation repos

[CybotTM]

Problem

The TYPO3-Documentation org has ~60 workflow files across ~29 repos with identical CI patterns (backport, docs rendering, PHP tests, code quality). When action SHAs change or tooling breaks (e.g. m-kuhn/backport@30b6e83 missing dist/index.js), each repo must be fixed individually.

Additionally, the org's GitHub Actions allow-list with SHA-pinned actions means composite actions that internally call other actions (like ramsey/composer-install → actions/cache@v4) break silently when inner SHAs change.

Solution

Add four reusable workflows to this repository (which already serves as the org's central CI/CD hub):

Workflow	Purpose
reusable-backport.yml	Backport merged PRs via korthout/backport-action
reusable-docs-render.yml	Documentation rendering check
reusable-php-quality.yml	Code quality: CS Fixer, PHPStan, XML lint
reusable-php-tests.yml	PHP test matrix (unit + integration)

Reusable workflows execute in this repo's context, so only this repo's action references need to stay current. Callers reference a single workflow and inherit all updates automatically.

Example caller (backport)

name: Backport
on:
  pull_request_target:
    types: [closed, labeled]

jobs:
  backport:
    uses: TYPO3-Documentation/t3docs-ci-deploy/.github/workflows/reusable-backport.yml@main
    with:
      label-pattern: "backport *"

All actions are SHA-pinned. Each workflow accepts optional inputs with sensible defaults.

Context

Requested by @linawolf in TYPO3-Documentation/TYPO3CMS-Reference-CoreApi#6414 (comment) — moving the workflows from netresearch/typo3-docs-ci-workflows into the org's own maintenance scope.

Benefits

• Single point of maintenance — update action SHAs once, all repos benefit
• Allow-list compatible — reusable workflows run in their own context, bypassing caller allow-list issues
• Consistent configuration — identical behavior across all repos
• Faster incident response — fix one repo instead of 29

[garvinhicking]

I think we should create a test first in a repo where SHA pinning is enabled before we roll it out. In my tests the @main syntax was also not allowed as a version pin even it was "inlined".

[linawolf]

Mergin the workflows to test them out we can always decide to move them afterwards

[CybotTM]

Hi @garvinhicking,

I think we should create a test first in a repo where SHA pinning is enabled before we roll it out. In my tests the @main syntax was also not allowed as a version pin even it was "inlined".

Dunno what you mean by "inlined"
AFAIK sha pinning rule affects only actions, not reusable (shared) workflows

https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization?utm_source=chatgpt.com#:~:text=Reusable%20workflows%20can%20still%20be%20referenced%20by%20tag

When you enable Require actions to be pinned to a full-length commit SHA, all actions must be pinned to a full-length commit SHA to be used. This includes actions from your organization and actions authored by GitHub. Reusable workflows can still be referenced by tag. For more information, see Secure use reference.