Skip to content

[TASK] Shared Reusable Workflows — Maintainer Guide & Checklist #7

@CybotTM

Description

@CybotTM

Overview

This issue provides a complete guide through the shared reusable workflows initiative for the TYPO3 Documentation organization. It consolidates all related PRs, issues, decisions, and action items in one place.

Goal: Centralize GitHub Actions workflows in TYPO3-Documentation/.github so that ~29 documentation repositories share a single maintained set of CI/CD workflows instead of each maintaining their own inline copies.

Background: The initiative started with TYPO3-Documentation/TYPO3CMS-Reference-CoreApi#6414 after the broken m-kuhn/backport@30b6e83 action (missing dist/index.js) required individual fixes across repos.
Workflows were initially placed in t3docs-ci-deploy (TYPO3-Documentation/t3docs-ci-deploy#56), then moved to .github per suggestion by @jaapio, implemented by @linawolf.

cc: @linawolf @garvinhicking @jaapio


Merge Checklist

PRs should be reviewed and merged in this order:

Phase 1: Foundation (.github repo)

Phase 2: Consumer repos (after Phase 1)

These can be merged in any order once Phase 1 is complete:

Phase 3: Strategy & future work


Available Shared Workflows

After #2 is merged, the repository provides 7 reusable workflows:

Workflow On main Purpose
reusable-backport.yml Automated backporting via labels
reusable-docs-render.yml Python/Composer-based doc rendering
reusable-php-quality.yml PHP CS Fixer + PHPStan
reusable-php-tests.yml PHP unit/integration test matrix
reusable-test-documentation.yml After #2 Docker-based doc rendering test
reusable-apply-precommit.yml After #2 Scheduled pre-commit whitespace fixes
reusable-php-command.yml After #2 Generic PHP + Composer + command

Key Decisions

Decision Rationale Reference
Use .github repo (not t3docs-ci-deploy) Org community health repo — workflows automatically trusted, no allow-list config needed ADR-002 in #3
Centralize workflows Single point of maintenance for action versions, consistent behavior, faster incident response ADR-001 in #3
Reference @main (not @SHA) SHA-pinning shared workflows reintroduces per-repo maintenance — defeats the purpose ADR-003 in #6 (proposed)

Related PRs (not part of this initiative but relevant)


Questions for maintainers

  1. Merge order — Does the proposed Phase 1 → Phase 2 → Phase 3 order work for you?
  2. Versioning — Please review [TASK] Add ADR-003: Versioning strategy for shared workflow references #6 (ADR-003) for the @main vs @tag vs @SHA decision.
  3. GettingStarted as test ground@linawolf suggested using GettingStarted for initial testing. Should we mark [TASK] Migrate workflows to shared reusable workflows from .github TYPO3CMS-Tutorial-GettingStarted#792 as the first consumer to merge?
  4. Branch protection — Should we add branch protection rules to this repo given that a broken push to main affects all consumers?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions