Settings

Die Probot Settings App synchronisiert die Repository-Konfiguration aus der Versionsverwaltung.

Die geteilten Regeln umfassen:

• Default-Branch, Beschreibung, Topics, Homepage
• Issue- und PR-Funktionen (Issues, Projects, Wiki, Pages, Downloads)
• Merge-Strategien (allow_squash_merge, allow_merge_commit, allow_rebase_merge)
• delete_branch_on_merge
• Branch-Protection für master und develop
• Geteilte Label-Palette

---

Verwendung

.github/settings.yml

_extends: gh-plumbing:.github/commons-settings.yml

repository:
  name: cookiecutter-gh-project
  description: Template for creating GitHub workflows and projects
  homepage: https://nolte.github.io/cookiecutter-gh-project
  topics: templating, cookiecutter, github

Overrides

Schlüssel in der lokalen .github/settings.yml überschreiben die geerbten Werte. Dort nur angeben, was vom geteilten Default abweicht.

---

Zentrale Konfiguration

.github/commons-settings.yml

---
# These settings are synced to GitHub by https://probot.github.io/apps/settings/
repository:

  # Either `true` to make the repository private, or `false` to make it public.
  private: false

  # Either `true` to enable issues for this repository, `false` to disable them.
  has_issues: true

  # Either `true` to enable projects for this repository, or `false` to disable them.
  # If projects are disabled for the organization, passing `true` will cause an API error.
  has_projects: true

  # Either `true` to enable the wiki for this repository, `false` to disable it.
  has_wiki: true

  has_pages: true

  # Either `true` to enable downloads for this repository, `false` to disable them.
  has_downloads: true

  # Updates the default branch for this repository.
  default_branch: develop

  # Merge strategy: squash-merge only.
  # Forcing a single linear-history strategy keeps `develop` clean and makes
  # release-drafter / Conventional-Commits parsing predictable across all
  # repositories that extend these commons.

  # Either `true` to allow squash-merging pull requests, or `false` to prevent
  # squash-merging.
  allow_squash_merge: true

  # Either `true` to allow merging pull requests with a merge commit, or `false`
  # to prevent merging pull requests with merge commits.
  allow_merge_commit: false

  # Either `true` to allow rebase-merging pull requests, or `false` to prevent
  # rebase-merging.
  allow_rebase_merge: false

  delete_branch_on_merge: true


# <!--td-commons-settings-labels-start-->
# Labels: define labels for Issues and Pull Requests
labels:
  - name: bug
    color: "#CC0000"
    description: An issue with the system.

  - name: enhancement
    color: "#336699"
    description: New functionality.

  - name: chore
    color: "#6e70ef"
    description: Maintenance

  - name: fix
    color: "#d73a4a"
    description: Conventional Commits type `fix` — bug fix.

  - name: feat
    color: "#a2eeef"
    description: Conventional Commits type `feat` — new feature.

  - name: docs
    color: "#0075ca"
    description: Conventional Commits type `docs` — documentation or spec change.

  - name: question
    color: "#3ffc8a"
    description: User question

  - name: documentation
    color: "#caa7e8"
    description: Update documentation.

  - name: cicd
    color: "#fbca04"
    description: ci/cd process functionality.

  - name: project-config
    color: "#ed979d"
    description: Change GitHub project config, keep a extra eye on merge.

  - name: breaking-change
    color: "#fc415d"
    description: Planed braking provider change.

  - name: duplicate
    color: "#cfd3d7"
    description: This issue or pull request already exists.

  - name: dependencies
    color: "#0366d6"
    description: Pull requests that update a dependency file.

  - name: wontfix
    color: "#ffffff"
    description: ""

  - name: automerge
    color: "#19F700"
    description: "Allow automatic Merge."

  - name: spec
    color: "#c5def5"
    description: Touches files under `spec/`.

  - name: skills
    color: "#bfdadc"
    description: Touches files under `skills/`.

  - name: agents
    color: "#c2e0c6"
    description: Touches files under `agents/`.

  - name: claude-code
    color: "#ffd33d"
    description: Touches Claude Code integration (`.claude/`, `.claude-plugin/`, `CLAUDE.md`).

  - name: release
    color: "#5319e7"
    description: Version-alignment PR — excluded from release-drafter changelog.

  - name: github-actions
    color: "#000000"
    description: Touches GitHub Actions workflows under `.github/workflows/`.

  - name: stale
    color: "#cccccc"
    description: Auto-applied by actions/stale to inactive issues and pull requests.

# <!--td-commons-settings-labels-end-->

branches:
  - name: master
    protection:
      required_pull_request_reviews: null
      required_status_checks: null
      enforce_admins: true
      # nolte-portfolio-app is the portfolio GitHub App that the cascade
      # remediation in #330 (Phase 1) wires through every cascade-emitting
      # reusable workflow. Declaring it as a push restriction actor here
      # enables the workflow-driven primary path of
      # spec/project/release-automation/ §Version-bearing file alignment:
      # `reusable-release-cd-refresh-master.yml` fast-forwards master with
      # the App token, and the push event cascades to other workflows.
      #
      # Consumers that own a personal account (not an organisation) cannot
      # honour `restrictions.apps` (GitHub limits this to organisation-owned
      # repositories); the Probot Settings App will skip the field silently
      # for those repositories. Such consumers either operate without
      # restrictions or override this block in their per-repo
      # .github/settings.yml.
      restrictions:
        users: []
        teams: []
        apps:
          - nolte-portfolio-app
  - name: develop
    protection:
      required_pull_request_reviews: null
      required_status_checks:
        # Portfolio-default leaves required contexts empty so this commons
        # config does not impose a gh-plumbing-specific check name on every
        # consumer repo. Consumers MUST declare their own required-check
        # contexts in their per-repo .github/settings.yml. See
        # spec/project/pull-request-workflow §required status checks.
        strict: true
        contexts: []
      enforce_admins: true
      restrictions:
        users: []
        teams: []
        apps:
          - nolte-portfolio-app

---

Versionierung, Drift und der _extends-Kontrakt

_extends @<ref> wird nicht unterstützt

Die Probot Settings App löst _extends: immer vom Default-Branch des Ziel-Repositories auf. Der Parser lehnt jeden Suffix @<tag>, @<sha>, ?ref=… oder :vN auf dem _extends:-Wert komplett ab. Er entfernt den Suffix nicht und fährt auch nicht fort. Siehe octokit-plugin-config/src/util/extends-to-get-content-params.ts — der reguläre Ausdruck verankert am Anfang und schließt @ aus dem Dateinamen-Token aus.

Operative Konsequenz. Jeder Konsument hängt für seine Probot-Konfiguration am aktuellen Stand von gh-plumbing/develop. Sobald sich eine commons-*.yml hier ändert, driftet jeder Konsument beim nächsten Sync-Trigger — ohne Signal zurück an den Konsumenten. Es gibt keinen reproduzierbaren Snapshot: die Frage „gegen welchen Stand von commons-settings.yml hat dieses Repository letzte Woche synchronisiert?" hat keine Antwort.

Das ist ein bekannter, akzeptierter Trade-off. Siehe Issue #337 für die vollständige Untersuchung (Parser-Quelltext, Alternativen-Matrix, Entscheidungsgrundlage).

Wann dieser Trade-off blockierend wird

Drei architektonische Alternativen stehen bereit, sobald Drift load-bearing wird:

Ansatz	Mechanismus	Pinning-Modell
github/safe-settings	Zentrales admin-Repository je Organisation, dreistufige Hierarchie (org/suborg/repo), PR-basierter Dry-Run im CI	Kein Pinning, aber eine einzige Quelle pro Organisation eliminiert repo-übergreifende _extends-Auflösungen
joshjohanning/bulk-github-repo-settings-sync-action	GitHub Action aus einem zentralen Repository, getriggert per Cron/Push; Eingaben sind Dateipfade im aufrufenden Repository	Action-Version plus Dateiinhalt an einem bestimmten Commit ergeben einen echten Snapshot
commons-*.yml in jeden Konsumenten inlinen	Inline-Kopie in der .github/settings.yml des Konsumenten mit Header # generated from gh-plumbing@<tag>; Renovate Custom Regex Manager bumpt den Header	Snapshot pro Konsumenten-Commit; vollständiger Diff im Bump-PR

Bis dahin gilt: Änderungen an commons-*.yml sind eine Public-API-Änderung und werden als Breaking Change ausgerollt.

Warum die lokale .github/settings.yml hier einen Propagation-Kommentar trägt

gh-plumbing ist Konsument seiner eigenen Commons. Die Probot App reagiert auf Push-Events, die die .github/settings.yml des Konsumenten berühren, nicht die obenliegende commons-*.yml. Um eine Commons-Änderung zu propagieren, muss die .github/settings.yml dieses Repositories ebenfalls angefasst werden (ein Kommentar-Bump genügt). Issue #331 hält diese Dog-Fooding-Eigenheit fest.