{"meta":{"title":"Configuration du référentiel pour le application Copilot GitHub","intro":"Définissez des instructions, des scripts et un comportement d’automatisation spécifiques au référentiel pour le GitHub Copilot app.","product":"GitHub Copilot","breadcrumbs":[{"href":"/fr/copilot","title":"GitHub Copilot"},{"href":"/fr/copilot/reference","title":"Informations de référence"},{"href":"/fr/copilot/reference/github-copilot-app-reference","title":"GitHub Copilot app référence"},{"href":"/fr/copilot/reference/github-copilot-app-reference/repository-configuration","title":"Configuration du référentiel"}],"documentType":"article"},"body":"# Configuration du référentiel pour le application Copilot GitHub\n\nDéfinissez des instructions, des scripts et un comportement d’automatisation spécifiques au référentiel pour le GitHub Copilot app.\n\nUtilisez-le `.github/github-app.yml` dans votre référentiel pour définir le GitHub Copilot app comportement de ce projet.\n\nVous pouvez également modifier ces paramètres de projet dans l’interface utilisateur de l’application. S’il `.github/github-app.yml` existe déjà, les modifications apportées à l’interface utilisateur sont réécrites dans ce fichier. S’il n’existe pas encore, vous pouvez le créer à partir des paramètres de projet actuels dans l’application.\n\n## À propos de l’emplacement du fichier de configuration\n\nCréez le fichier à l’adresse suivante :\n\n```text copy\n.github/github-app.yml\n```\n\nL’application prend également en charge le nom de fichier `.github/copilot-desktop.yml` hérité pour la compatibilité descendante.\n\nPour connaître les étapes de personnalisation basées sur l’interface utilisateur, consultez [Personnalisation de l’application GitHub Copilot](/fr/copilot/how-tos/github-copilot-app/customize-github-copilot-app).\n\n## Examiner et approuver la configuration\n\nLorsque l’application détecte une configuration à partir du référentiel, elle n’applique pas d’instructions de référentiel, de scripts ou d’autres paramètres à partir du fichier tant que vous n’avez pas examiné et accepté la configuration. Cela vous protège contre l’exécution de commandes ou l’application de paramètres ajoutés par un autre contributeur. Les configurations que vous créez ou mettez à jour via l’interface utilisateur de l’application sont approuvées automatiquement.\n\n> \\[!WARNING]\n> Avant d’accepter une configuration de référentiel, passez en revue chaque commande configurée et les dépendances qu’il exécute. Les scripts et leurs processus enfants reçoivent les GitHub informations d’identification décrites plus loin dans cet article. Par conséquent, ne les configurez jamais pour journaliser ou conserver ces variables d’environnement.\n\nSi le fichier change en dehors de l’application, y compris les modifications apportées à l’espace blanc ou aux commentaires, vous devez passer en revue et accepter la configuration mise à jour avant que l’application ne l’applique. Tant que vous n’acceptez pas la version actuelle, l’application continue d’utiliser les paramètres de projet précédemment configurés dans l’application.\n\n## Exemple de configuration\n\n```yaml copy\ninstructions: |\n  Use bun instead of npm.\n\nscripts:\n  - name: Setup\n    command: bun install\n    triggers:\n      - session.create\n  - name: Run\n    command: bun run dev\n  - name: Archive cleanup\n    command: rm -rf node_modules\n    triggers:\n      - session.archive\n\nserver_ready_pattern: '(?i)Local:\\s+(https?://\\S+)'\nauto_open_in_browser: true\n\nautomation:\n  auto_issue_session: true\n  remote_control: false\n```\n\n## Configurer des instructions et des scripts\n\n### `instructions`\n\nPermet `instructions` d’ajouter des instructions spécifiques au référentiel à l’invite système pour les sessions du projet. Si vous configurez également des instructions globales dans l’application, les instructions globales sont appliquées en premier, suivies des instructions du projet.\n\n### `scripts`\n\nPermet `scripts` de définir des commandes qui apparaissent dans l’application et peuvent s’exécuter manuellement ou sur des déclencheurs spécifiques.\n\nChaque élément de script prend en charge :\n\n* `name` (`string`) : nom d’affichage dans l’interface utilisateur.\n* `command` (`string`) : Commande à exécuter.\n* `triggers` (`string[]`facultatif) : événements qui exécutent automatiquement le script.\n\nLes scripts sans `triggers` être manuels.\n\n### Valeurs du déclencheur\n\nUtilisez des valeurs de déclencheur canonique dans votre fichier :\n\n* `session.create`\n* `session.archive`\n\nL’application accepte également ces alias hérités lors de l’analyse des fichiers existants :\n\n* `workspace.create` (alias pour `session.create`)\n* `workspace.archive` (alias pour `session.archive`)\n\nLorsqu’un script déclenché s’exécute, `COPILOT_SCRIPT_TRIGGER` est défini sur la valeur canonique :\n\n* `session.create`\n* `session.archive`\n\n## Configurer la détection du serveur et le comportement du navigateur\n\n### `server_ready_pattern`\n\n`server_ready_pattern` est une expression régulière utilisée pour détecter quand un script d’exécution a démarré un serveur.\n\nLes modèles utilisent la syntaxe prise en charge par la caisse de `regex` Rust. Pour plus d’informations sur la syntaxe, consultez [Syntaxe](https://docs.rs/regex/1/regex/#syntax) dans la documentation sur la caisse. Si le modèle n’est pas valide, l’application utilise son modèle de détection de serveur par défaut.\n\nUtilisez un premier groupe de capture pour l’URL ou le port détecté. L’application lit le groupe `1`de captures :\n\n* Si la capture est une URL (`http://...` ou `https://...`), l’URL est utilisée.\n* Si la capture n’est qu’un numéro de port (par exemple `3000`), l’application la convertit en `http://localhost:3000`.\n\n### `auto_open_in_browser`\n\nSi `auto_open_in_browser` c’est `true`le cas, l’application ouvre l’URL d’exécution détectée dans le navigateur intégré. Si ce champ est omis, la valeur par défaut effective est `true`.\n\n## Configurer le comportement d’automatisation\n\nDéfinir les options d’automatisation sous `automation`:\n\n* `automation.auto_issue_session` (`boolean`) contrôle si l’application démarre automatiquement une session avec un contexte de problème. En cas d’omission, la valeur par défaut effective est `true`.\n* `automation.remote_control` (`boolean`) contrôle si les sessions sont accessibles à partir de l’interface GitHub web ou GitHub Mobile. En cas d’omission, la valeur par défaut effective est `false`.\n\nSi votre Copilot siège provient d’une organisation, la stratégie « Stocker les sessions locales dans le cloud » applicable doit être définie sur « Afficher et contrôler » pour que le contrôle à distance soit disponible. Les paramètres gérés par l’entreprise `remoteControl` peuvent restreindre davantage le contrôle à distance, même si c’est `automation.remote_control`le cas`true`. Pour plus d’informations, consultez « [Concernant le contrôle à distance des sessions GitHub Copilot CLI](/fr/copilot/concepts/agents/copilot-cli/about-remote-control) » et « [Paramètres gérés par l’entreprise](/fr/copilot/reference/enterprise-administrators/enterprise-managed-settings) ».\n\n## Variables d’environnement runtime pour les scripts\n\nLes scripts s’exécutent avec ces variables d’environnement fournies par l’application :\n\n| Variable                 | Description                                                                                            |\n| ------------------------ | ------------------------------------------------------------------------------------------------------ |\n| `COPILOT_WORKSPACE_NAME` | Nom de l’espace de travail actuel.                                                                     |\n| `COPILOT_WORKSPACE_PATH` | Chemin absolu de l’espace de travail.                                                                  |\n| `COPILOT_ROOT_PATH`      | Chemin absolu de l’extraction racine du projet.                                                        |\n| `COPILOT_DEFAULT_BRANCH` | Project branche par défaut.                                                                            |\n| `COPILOT_PORT`           | Port WebSocket d’application pour le contexte d’espace de travail actuel.                              |\n| `COPILOT_SCRIPT_TRIGGER` | Déclencheur qui a lancé le script (défini uniquement pour les scripts déclenchés).                     |\n| `GH_TOKEN`               | Jeton pour le compte sélectionné GitHub .                                                              |\n| `GH_HOST`                | Hôte du compte sélectionné GitHub .                                                                    |\n| `COPILOT_GH_ACCOUNT_*`   | Jetons spécifiques à l’hôte et au compte pour chaque compte connecté, y compris le compte sélectionné. |\n\nPour chaque `COPILOT_GH_ACCOUNT_*` variable, l’application en minuscules l’hôte et la connexion, laisse les lettres ASCII et les chiffres inchangés, et remplace tous les autres octets UTF-8 par sa valeur hexadécimale en majuscules entourée de traits de soulignement. Le nom de la variable utilise le format `COPILOT_GH_ACCOUNT_<HOST>_<LOGIN>`. Par exemple, le jeton pour `alice` activé `github.com` est `COPILOT_GH_ACCOUNT_github_2E_com_alice`, et le jeton pour `user` activé `ghe-example.com` est `COPILOT_GH_ACCOUNT_ghe_2D_example_2E_com_user`.\n\n## Compatibilité héritée\n\nPour une compatibilité descendante, l’application peut toujours analyser l’ancienne forme basée sur `scripts` des objets :\n\n```yaml copy\nscripts:\n  setup: bun install\n  run: bun run dev\n  archive: rm -rf node_modules\n```\n\nDans cette forme héritée :\n\n* `setup` mappe à un script avec le déclencheur de création.\n* `archive` mappe à un script avec le déclencheur d’archivage.\n* `run` mappe aux entrées de script manuelles et peut être une chaîne de commande unique ou une liste d’objets `{ name, command }` ."}