Référence de configuration

Le fichier de configuration central pilote tout le comportement d’application, de synchronisation et de dispatch. Il se trouve dans .github/config/repo-settings.json dans docs-control et est récupéré par les dépôts en aval lors de l’exécution du workflow.

{
  "_comment": "Central repo-settings config — enforced by enforce-repo-settings.yml",
  "repository": {
    "private": false,
    "has_issues": true,
    "has_projects": false,
    "has_wiki": false,
    "is_template": false,
    "allow_squash_merge": true,
    "allow_merge_commit": true,
    "allow_rebase_merge": true,
    "allow_auto_merge": false,
    "delete_branch_on_merge": true,
    "web_commit_signoff_required": false,
    "squash_merge_commit_title": "COMMIT_OR_PR_TITLE",
    "squash_merge_commit_message": "COMMIT_MESSAGES",
    "merge_commit_title": "MERGE_MESSAGE",
    "merge_commit_message": "PR_TITLE",
    "allow_update_branch": true,
    "homepage": ""
  },
  "actions_permissions": {
    "default_workflow_permissions": "write",
    "can_approve_pull_request_reviews": true
  },
  "branch_protection": [
    {
      "branch": "main",
      "enforce_admins": true,
      "required_status_checks": {
        "strict": true,
        "contexts": [
          "Check linked issues",
          "lint / Lint Code Base",
          "lint / Shell Unit Tests"
        ],
        "self_contexts": ["Check linked issues", "Lint Code Base", "Shell Unit Tests"]
      },
      "required_pull_request_reviews": {
        "dismiss_stale_reviews": false,
        "require_code_owner_reviews": false,
        "required_approving_review_count": 0,
        "require_last_push_approval": false,
        "dismissal_restrictions": {
          "users": [],
          "teams": []
        },
        "bypass_pull_request_allowances": {
          "users": [],
          "teams": [],
          "apps": []
        }
      },
      "restrictions": null,
      "required_linear_history": false,
      "allow_force_pushes": false,
      "allow_deletions": false,
      "block_creations": false,
      "required_conversation_resolution": false,
      "lock_branch": false,
      "allow_fork_syncing": false
    }
  ],
  "topics": [],
  "pages": {
    "enabled": true,
    "build_type": "workflow"
  },
  "managed_files": {
    "source_repo": "f5-sales-demo/docs-control",
    "files": [
      {"src": "workflows/github-pages-deploy.yml", "dest": ".github/workflows/github-pages-deploy.yml"},
      {"src": "workflows/enforce-repo-settings.yml", "dest": ".github/workflows/enforce-repo-settings.yml"},
      {"src": "workflows/require-linked-issue.yml", "dest": ".github/workflows/require-linked-issue.yml"},
      {"src": "workflows/antigravity-review.yml", "dest": ".github/workflows/antigravity-review.yml"},
      {"src": "workflows/antigravity-translate.yml", "dest": ".github/workflows/antigravity-translate.yml"},
      {"src": ".github/PULL_REQUEST_TEMPLATE.md", "dest": ".github/PULL_REQUEST_TEMPLATE.md"},
      {"src": ".github/ISSUE_TEMPLATE/bug_report.md", "dest": ".github/ISSUE_TEMPLATE/bug_report.md"},
      {"src": ".github/ISSUE_TEMPLATE/feature_request.md", "dest": ".github/ISSUE_TEMPLATE/feature_request.md"},
      {"src": ".github/ISSUE_TEMPLATE/documentation.md", "dest": ".github/ISSUE_TEMPLATE/documentation.md"},
      {"src": ".github/ISSUE_TEMPLATE/config.yml", "dest": ".github/ISSUE_TEMPLATE/config.yml"},

      {"src": "CONTRIBUTING.md", "dest": "CONTRIBUTING.md"},
      {"src": "CLAUDE.md", "dest": "CLAUDE.md"},
      {"src": "AGENTS.md", "dest": "AGENTS.md"},
      {"src": ".agents/skills/demo-components/SKILL.md", "dest": ".agents/skills/demo-components/SKILL.md"},
      {"src": ".agents/skills/i18n-translate/SKILL.md", "dest": ".agents/skills/i18n-translate/SKILL.md"},
      {"src": ".editorconfig", "dest": ".editorconfig"},
      {"src": ".gitignore", "dest": ".gitignore"},
      {"src": "LICENSE", "dest": "LICENSE"},
      {"src": ".pre-commit-config.yaml", "dest": ".pre-commit-config.yaml"}
    ]
  }
}

Référence des champs

`repository`

Paramètres de dépôt GitHub standards appliqués via PATCH /repos/{owner}/{repo}. Chaque clé correspond directement au champ de l’API GitHub. Le workflow d’application compare chaque clé à la valeur actuelle du dépôt et ne corrige que les clés qui ont dérivé.

Paramètres notables :

delete_branch_on_merge: true — nettoie automatiquement les branches de PR fusionnées
allow_update_branch: true — active le bouton “Update branch” sur les PRs
homepage: "" — calculé automatiquement lors de l’exécution comme https://f5-sales-demo.github.io/{repo}/

`actions_permissions`

Contrôle les permissions des workflows GitHub Actions pour le dépôt :

default_workflow_permissions: "write" — les workflows obtiennent un accès en lecture/écriture au dépôt par défaut
can_approve_pull_request_reviews: true — permet aux workflows d’approuver les PRs

Contrôles d’automatisation Antigravity

Le workflow Configure Antigravity Controls modifie les variables d’organisation qui régissent le vérificateur et le traducteur Antigravity. Chaque phase peut être réexécutée en toute sécurité :

disabled définit les deux variables sur false avec une visibilité all.
pilot définit les deux variables sur true avec une visibilité selected restreinte à docs-control.
all définit les deux variables sur true avec une visibilité all uniquement après avoir validé le recu de révision exact-head du pilote sélectionné et la publication de la traduction dans les 12 locales.

Le workflow utilise le jeton d’accès personnel de gouvernance existant, des réessais limités de l’API GitHub et des battements de cœur de progression structurés. Il ne nécessite pas d’application GitHub ni de fonctionnalités GitHub Enterprise.

`branch_protection`

Un tableau de règles de protection des branches. Chaque entrée spécifie un nom de branch et les paramètres de protection souhaités. Actuellement, seul main est protégé.

Champs clés :

enforce_admins: true — les règles de protection s’appliquent également aux administrateurs du dépôt
required_status_checks.strict: true — les branches doivent être à jour avant la fusion
required_status_checks.contexts — les noms de vérification que les dépôts en aval doivent valider (par exemple, Check linked issues et lint / Shell Unit Tests)
required_status_checks.self_contexts — les noms de vérification que docs-control lui-même doit valider (par exemple, Check linked issues et Shell Unit Tests)
required_pull_request_reviews — exige que toutes les modifications passent par une pull request tandis que required_approving_review_count: 0 maintient l’approbation humaine optionnelle ; les listes de rejet et de contournement restent vides
restrictions: null — aucune restriction de push au-delà de la protection des branches

`contexts` par rapport à `self_contexts`

Les vérifications de workflow réutilisables dans les dépôts en aval utilisent <caller_job_key> / <reusable_job_name>, tandis que docs-control signale leurs noms de job bruts. La porte des tickets liés fait exception : son workflow planifié publie directement le statut de commit Check linked issues dans chaque dépôt, de sorte que contexts et self_contexts doivent tous deux utiliser ce nom exact.

Le champ self_contexts stocke les noms de vérification qui s’appliquent à docs-control lui-même. Pendant l’application, le workflow détecte s’il s’exécute sur le dépôt source et remplace contexts par self_contexts avant d’appliquer la protection des branches. Le champ self_contexts est toujours supprimé avant d’envoyer la charge utile à l’API GitHub.

Shell Unit Tests est la porte de test de dépôt uniforme. Le workflow réutilisable la signale toujours : les dépôts consommateurs exécutent chaque fichier tests/test-*.sh, tandis qu’un dépôt sans tests correspondants signale un succès avec un message explicite indiquant l’absence de tests. Cela rend les tests shell de dépôt obligatoires par défaut au lieu de s’appuyer sur des listes d’adhésion par dépôt.

Profils de tests shell consommateurs

La configuration par défaut suppose que chaque script tests/test-*.sh au niveau racine est hermétique sur un runner hébergé par GitHub non provisionné. Un dépôt qui stocke également des tests d’intégration de conteneur ou de service sous ce glob nécessite une entrée consumer_shell_tests.profiles dans repo-settings.json.

Chaque profil classe l’inventaire correspondant complet :

Les entrées unit contiennent un path de test et un tableau args. Le runner passe chaque argument littéralement, sans évaluation shell.
Les entrées environment contiennent un path de test et un motif reason non vide expliquant pourquoi la porte unitaire du runner brut ne peut pas l’exécuter.

Le workflow réutilisable récupère le sélecteur et la configuration depuis la même révision main de docs-control, enregistre cette révision et valide l’inventaire avant de lancer quoi que ce soit. Une configuration manquante, des chemins ou arguments non sécurisés, des chemins en double et des tests non classés ou manquants font échouer le contexte requis. Cela fait d’un profil un contrat de classification audité plutôt qu’une liste d’exclusion. Les dépôts sans profil conservent la valeur par défaut globale.

La substitution xcsh exclut les deux contextes Super-Linter car ce dépôt n’appelle pas le workflow réutilisable Super-Linter ; ses contextes natifs check, pii-guard et test restent obligatoires. Une vérification en direct doit prouver qu’une exclusion est nécessaire avant d’être ajoutée.

Ne requérez pas un contexte provenant d’un workflow comportant des filtres paths ou paths-ignore. GitHub laisse ce contexte en attente lorsque le workflow ne démarre pas. Les outils de sécurité globaux doivent s’exécuter dans un workflow de pull request non filtré ou dans un audit complet planifié ; l’audit de sécurité géré des workflows utilise ce dernier modèle pour zizmor. Une condition au niveau du job est sûre car un job ignoré signale toujours une vérification réussie.

`topics`

Un tableau de sujets GitHub à appliquer au dépôt. Actuellement vide — les sujets ne sont pas appliqués.

`pages`

Configuration de GitHub Pages :

enabled: true — garantit que Pages est activé sur chaque dépôt inscrit
build_type: "workflow" — utilise GitHub Actions pour le build de Pages (et non les builds basés sur des branches hérités)

`managed_files`

Définit le manifeste de synchronisation de fichiers :

source_repo — le dépôt qui détient les versions canoniques des fichiers gérés (f5-sales-demo/docs-control)
files — un tableau d’objets {src, dest} associant les chemins sources dans docs-control aux chemins de destination dans les dépôts en aval

Le workflow de synchronisation de fichiers parcourt ce tableau pour détecter et corriger la dérive. Les fichiers non répertoriés ici (comme dependabot.yml et README.md) sont générés dynamiquement plutôt que synchronisés à partir de sources statiques.

Référence de configuration

Référence des champs

repository

actions_permissions

Contrôles d’automatisation Antigravity

branch_protection

contexts par rapport à self_contexts