Configuration du référentiel pour le application Copilot GitHub

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

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

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

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

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 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 1de 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 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 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_controlle castrue. Pour plus d’informations, consultez « Concernant le contrôle à distance des sessions CLI GitHub Copilot » 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 :

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

Compatibilité héritée

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

scripts:
  setup: bun install
  run: bun run dev
  archive: rm -rf node_modules

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