Configuration du dépôt pour l’application GitHub Copilot

Utilisez .github/github-app.yml dans votre référentiel pour définir comment GitHub Copilot app le 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 enregistrées 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

.github/github-app.yml

.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.

Examiner la configuration et lui faire confiance

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 considérées automatiquement comme fiables.

Avertissement

Avant d’accepter une configuration de référentiel, passez en revue chaque commande configurée et les dépendances qu’elles exécutent. 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

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

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`

Utilisez instructions pour 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`

Utilisez scripts pour 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 du script prend en charge:

name (string) : nom d’affichage dans l’interface utilisateur.
command (string): Commande à lancer.
triggers (string[]facultatif) : événements qui exécutent automatiquement le script.

Les scripts sans triggers sont manuels.

Valeurs de déclenchement

Utilisez des valeurs de déclenchement canoniques 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 de 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 de tâche a démarré un serveur.

Les modèles utilisent la syntaxe prise en charge par le crate regex de Rust. Pour plus d’informations sur la syntaxe, consultez Syntaxe dans la documentation du crate. Si le motif n’est pas valide, l’application utilise son motif 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 de capture 1 :

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 truele 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 le contexte de l’anomalie. 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 web GitHub ou à partir de GitHub Mobile. En cas d’omission, la valeur par défaut effective est false.

Si votre Copilot licence 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 lorsque automation.remote_controlc’est le castrue. Pour plus d’informations, consultez « Contrôle à distance des GitHub Copilot CLI sessions » et « Paramètres gérés par l’entreprise ».

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 la copie de travail racine du projet.
`COPILOT_DEFAULT_BRANCH`	Branche par défaut du projet
`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 d’accès 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 met l’hôte et la connexion en minuscules, laisse les lettres ASCII et les chiffres inchangés, et remplace tous les autres octets UTF-8 par leur 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 sur github.com est COPILOT_GH_ACCOUNT_github_2E_com_alice, et le jeton pour user sur ghe-example.com est COPILOT_GH_ACCOUNT_ghe_2D_example_2E_com_user.

Compatibilité avec les versions antérieures

Pour une compatibilité descendante, l’application peut toujours analyser l’ancienne forme scripts basée sur des objets :