# Configuration du référentiel pour le application Copilot GitHub Définissez des instructions, des scripts et un comportement d’automatisation spécifiques au référentiel pour le GitHub Copilot app. Utilisez-le `.github/github-app.yml` dans votre référentiel pour définir le GitHub Copilot app comportement de ce projet. Vous 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. ## À propos de l’emplacement du fichier de configuration Créez le fichier à l’adresse suivante : ```text copy .github/github-app.yml ``` L’application prend également en charge le nom de fichier `.github/copilot-desktop.yml` hérité pour la compatibilité descendante. Pour 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). ## Examiner et approuver la configuration Lorsque 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. > \[!WARNING] > 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. Si 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. ## Exemple de configuration ```yaml copy instructions: | Use bun instead of npm. scripts: - name: Setup command: bun install triggers: - session.create - name: Run command: bun run dev - name: Archive cleanup command: rm -rf node_modules triggers: - session.archive server_ready_pattern: '(?i)Local:\s+(https?://\S+)' auto_open_in_browser: true automation: auto_issue_session: true remote_control: false ``` ## Configurer des instructions et des scripts ### `instructions` Permet `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. ### `scripts` Permet `scripts` de définir des commandes qui apparaissent dans l’application et peuvent s’exécuter manuellement ou sur des déclencheurs spécifiques. Chaque élément de script prend en charge : * `name` (`string`) : nom d’affichage dans l’interface utilisateur. * `command` (`string`) : Commande à exécuter. * `triggers` (`string[]`facultatif) : événements qui exécutent automatiquement le script. Les scripts sans `triggers` être manuels. ### Valeurs du déclencheur Utilisez des valeurs de déclencheur canonique dans votre fichier : * `session.create` * `session.archive` L’application accepte également ces alias hérités lors de l’analyse des fichiers existants : * `workspace.create` (alias pour `session.create`) * `workspace.archive` (alias pour `session.archive`) Lorsqu’un script déclenché s’exécute, `COPILOT_SCRIPT_TRIGGER` est défini sur la valeur canonique : * `session.create` * `session.archive` ## Configurer la détection du serveur et le comportement du navigateur ### `server_ready_pattern` `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. Les 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. Utilisez un premier groupe de capture pour l’URL ou le port détecté. L’application lit le groupe `1`de captures : * Si la capture est une URL (`http://...` ou `https://...`), l’URL est utilisée. * Si la capture n’est qu’un numéro de port (par exemple `3000`), l’application la convertit en `http://localhost:3000`. ### `auto_open_in_browser` Si `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`. ## Configurer le comportement d’automatisation Définir les options d’automatisation sous `automation`: * `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`. * `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`. Si 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) ». ## Variables d’environnement runtime pour les scripts Les scripts s’exécutent avec ces variables d’environnement fournies par l’application : | Variable | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------ | | `COPILOT_WORKSPACE_NAME` | Nom de l’espace de travail actuel. | | `COPILOT_WORKSPACE_PATH` | Chemin absolu de l’espace de travail. | | `COPILOT_ROOT_PATH` | Chemin absolu de l’extraction racine du projet. | | `COPILOT_DEFAULT_BRANCH` | Project branche par défaut. | | `COPILOT_PORT` | Port WebSocket d’application pour le contexte d’espace de travail actuel. | | `COPILOT_SCRIPT_TRIGGER` | Déclencheur qui a lancé le script (défini uniquement pour les scripts déclenchés). | | `GH_TOKEN` | Jeton pour le compte sélectionné GitHub . | | `GH_HOST` | Hôte du compte sélectionné GitHub . | | `COPILOT_GH_ACCOUNT_*` | Jetons spécifiques à l’hôte et au compte pour chaque compte connecté, y compris le compte sélectionné. | Pour 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__`. 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`. ## Compatibilité héritée Pour une compatibilité descendante, l’application peut toujours analyser l’ancienne forme basée sur `scripts` des objets : ```yaml copy scripts: setup: bun install run: bun run dev archive: rm -rf node_modules ``` Dans cette forme héritée : * `setup` mappe à un script avec le déclencheur de création. * `archive` mappe à un script avec le déclencheur d’archivage. * `run` mappe aux entrées de script manuelles et peut être une chaîne de commande unique ou une liste d’objets `{ name, command }` .