CI/CD und Governance

Das Repository verwendet vier GitHub Actions Workflows und ein zentralisiertes Template-System für die Governance.

Workflows

Workflow	Datei	Auslöser	Zweck
GitHub Pages Deploy	github-pages-deploy.yml	Push auf main (docs/**), manueller Dispatch	Erstellt und veröffentlicht die Dokumentationsseite auf GitHub Pages
Build and Publish Docker Image	build-image.yml	Push auf main (docker/**, package*.json), täglicher Cron, repository_dispatch	Erstellt das Docker-Image, pusht zu GHCR und löst Rebuilds in nachgelagerten Repos aus
Require Linked Issue	require-linked-issue.yml	Pull-Request-Events	Blockiert PRs, die kein GitHub Issue referenzieren
Enforce Repository Settings	enforce-repo-settings.yml	Alle 6 Stunden, Push auf Settings-Konfiguration, manueller Dispatch	Wendet standardisierte Repository-Einstellungen aus dem Template an

GitHub Pages Deploy

on:
  push:
    branches: [main]
    paths:
      - 'docs/**'
  workflow_dispatch:

Delegiert an einen wiederverwendbaren Workflow im Template-Repository:

jobs:
  docs:
    uses: f5-sales-demo/docs-control/.github/workflows/github-pages-deploy.yml@main

Berechtigungen: contents: read, packages: read, pages: write, id-token: write. Verwendet die Concurrency-Gruppe pages mit cancel-in-progress: true, um veraltete Deployments zu vermeiden.

Wird nur bei Push ausgelöst, wenn sich Dateien unter docs/ ändern. Kann auch manuell über workflow_dispatch ausgelöst werden – so löst der Dispatch-Job in build-image.yml nachgelagerte Rebuilds aus.

Build and Publish Docker Image

on:
  push:
    branches: [main]
    paths:
      - 'docker/**'
      - 'package.json'
      - 'package-lock.json'
  schedule:
    - cron: '0 6 * * *'
  repository_dispatch:
    types: [rebuild-image]

Schritte:

1. Code auschecken
2. Anmeldung bei ghcr.io mittels docker/login-action
3. Build und Push mittels docker/build-push-action mit Kontext . und Datei docker/Dockerfile
4. Tags: ghcr.io/<owner>/<repo>:latest und ghcr.io/<owner>/<repo>:<sha>

Nach einem erfolgreichen Build löst der Dispatch-Job github-pages-deploy.yml per workflow_dispatch in jedem nachgelagerten Repository aus, das in der downstream-repos.json-Konfiguration des Template-Repositories aufgeführt ist. Dadurch wird sichergestellt, dass alle Content-Repos ihre Dokumentation mit dem aktualisierten Builder-Image neu erstellen.

Der tägliche Cron stellt sicher, dass das Image auch ohne Code-Änderungen aktuell bleibt (erfasst Abhängigkeitsaktualisierungen). Das repository_dispatch-Event ermöglicht es externen Systemen, einen Rebuild auszulösen.

Wird nur bei Push ausgelöst, wenn sich docker/-Dateien oder package*.json ändern. Reine Dokumentationsänderungen lösen keinen Image-Rebuild aus.

Require Linked Issue

on:
  pull_request_target:
    types: [opened, edited, reopened, synchronize]

Verwendet nearform-actions/github-action-check-linked-issues@v1, um sicherzustellen, dass jeder PR ein GitHub Issue referenziert (z. B. Closes #42 in der Beschreibung). Dependabot-PRs werden ausgeschlossen über:

exclude-branches: "dependabot/**"

Eine benutzerdefinierte Nachricht informiert Mitwirkende über das erwartete Format, wenn die Prüfung fehlschlägt. Siehe CONTRIBUTING.md für den vollständigen Contributor-Workflow.

Enforce Repository Settings

on:
  schedule:
    - cron: '0 */6 * * *'
  push:
    branches: [main]
    paths:
      - '.github/config/repo-settings.json'
  workflow_dispatch:

Delegiert an einen wiederverwendbaren Workflow im Template-Repository:

jobs:
  enforce:
    uses: f5-sales-demo/docs-control/.github/workflows/enforce-repo-settings.yml@main
    secrets:
      repo-admin-token: ${{ secrets.REPO_ADMIN_TOKEN }}

Läuft alle 6 Stunden und bei Änderungen an der Settings-Konfigurationsdatei. Wendet Branch-Schutzregeln, Merge-Einstellungen und andere Repository-Konfigurationen aus .github/config/repo-settings.json an.

Governance-Modell

Zentralisiertes Template

Das Repository f5-sales-demo/docs-control ist die einzige Quelle der Wahrheit für:

• Wiederverwendbare Workflow-Definitionen (Docs-Deploy, Repository-Settings-Durchsetzung)
• Verwaltete Dateien, die über alle Repos in der Organisation synchronisiert werden
• Standardkonfigurationen und Branch-Schutzregeln

Dieser Builder und alle Content-Repos erben ihr CI/CD-Verhalten vom Template.

Synchronisierung verwalteter Dateien

Das Template-Repository kann verwaltete Dateien (wie Workflow-Definitionen und Konfigurationsdateien) an nachgelagerte Repos pushen. Dies hält alle Repositories ohne manuelle Aktualisierungen synchron. Die Synchronisierung läuft über einen separaten Workflow im Template-Repository.

Branch-Schutz

Der Enforce-Repo-Settings-Workflow wendet Branch-Schutzregeln aus dem Template an, darunter:

• Erforderliche Status-Checks vor dem Merge
• Erforderliche Linked-Issue-Prüfung
• Bevorzugter Squash-Merge
• Automatisches Löschen von Head-Branches nach dem Merge

Secrets

Secret	Quelle	Zweck
GITHUB_TOKEN	Automatisch (GitHub)	Wird von den meisten Workflows für Checkout, Paketveröffentlichung und API-Aufrufe verwendet
REPO_ADMIN_TOKEN	Manuell (Repository-Secret)	Erforderlich für Enforce-Repo-Settings und den Dispatch-Job zum Ändern von Branch-Schutz, Repository-Einstellungen und zum Auslösen nachgelagerter Workflows (benötigt Admin-Berechtigung)