# Repositorykonfiguration für die GitHub-App Copilot Definieren Sie repositoryspezifische Anweisungen, Skripts und Automatisierungsverhalten für das GitHub Copilot app. Verwenden Sie `.github/github-app.yml` in Ihrem Repository, um zu definieren, wie sich das Verhalten für dieses GitHub Copilot app Projekt verhalten soll. Sie können diese Projekteinstellungen auch in der App-UI bearbeiten. Falls `.github/github-app.yml` bereits vorhanden, werden UI-Änderungen in diese Datei zurückgeschrieben. Wenn sie noch nicht vorhanden ist, können Sie sie aus den aktuellen Projekteinstellungen in der App erstellen. ## Informationen zum Speicherort der Konfigurationsdatei Erstellen Sie die Datei unter: ```text copy .github/github-app.yml ``` Die App unterstützt auch den Legacydateinamen `.github/copilot-desktop.yml` aus Gründen der Abwärtskompatibilität. Informationen zu UI-basierten Anpassungsschritten finden Sie unter [Anpassen der GitHub-App Copilot](/de/copilot/how-tos/github-copilot-app/customize-github-copilot-app). ## Überprüfen und Vertrauen der Konfiguration Wenn die App eine Konfiguration aus dem Repository erkennt, wendet sie keine Repositoryanweisungen, Skripts oder andere Einstellungen aus der Datei an, bis Sie die Konfiguration überprüfen und akzeptieren. Dadurch können Sie keine Befehle ausführen oder Einstellungen anwenden, die von einem anderen Mitwirkenden hinzugefügt wurden. Konfigurationen, die Sie über die App-UI erstellen oder aktualisieren, werden automatisch als vertrauenswürdig eingestuft. > \[!WARNING] > Bevor Sie eine Repositorykonfiguration akzeptieren, überprüfen Sie alle konfigurierten Befehle und die ausgeführten Abhängigkeiten. Skripts und ihre untergeordneten Prozesse erhalten die GitHub weiter unten in diesem Artikel beschriebenen Anmeldeinformationen, sodass sie niemals so konfiguriert werden, dass diese Umgebungsvariablen protokolliert oder beibehalten werden. Wenn sich die Datei außerhalb der App ändert, einschließlich Änderungen an Leerzeichen oder Kommentaren, müssen Sie die aktualisierte Konfiguration überprüfen und akzeptieren, bevor die App sie anwendet. Bis Sie die aktuelle Version akzeptieren, verwendet die App weiterhin die Projekteinstellungen, die zuvor in der App konfiguriert wurden. ## Beispielkonfiguration ```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 ``` ## Konfigurieren von Anweisungen und Skripts ### `instructions` Hier können `instructions` Sie repositoryspezifische Anleitungen zur Systemaufforderung für Sitzungen im Projekt hinzufügen. Wenn Sie auch globale Anweisungen in der App konfigurieren, werden zuerst die globalen Anweisungen angewendet, gefolgt von den Projektanweisungen. ### `scripts` Hiermit definieren Sie `scripts` Befehle, die in der App angezeigt werden, und können manuell oder auf bestimmten Triggern ausgeführt werden. Jedes Skriptelement unterstützt Folgendes: * `name` (`string`): Anzeigename in der Benutzeroberfläche. * `command` (`string`): Auszuführender Befehl. * `triggers` (`string[]`, optional): Ereignisse, die das Skript automatisch ausführen. Skripts ohne `triggers` manuell. ### Triggerwerte Verwenden Sie kanonische Triggerwerte in Ihrer Datei: * `session.create` * `session.archive` Die App akzeptiert auch diese Legacyalias beim Analysieren vorhandener Dateien: * `workspace.create` (Alias für `session.create`) * `workspace.archive` (Alias für `session.archive`) Wenn ein ausgelöstes Skript ausgeführt wird, `COPILOT_SCRIPT_TRIGGER` wird auf den kanonischen Wert festgelegt: * `session.create` * `session.archive` ## Konfigurieren der Servererkennung und des Browserverhaltens ### `server_ready_pattern` `server_ready_pattern` ist ein regulärer Ausdruck, der verwendet wird, um zu erkennen, wann ein Ausführungsskript einen Server gestartet hat. Muster verwenden die syntax, die von Rusts `regex` Kasten unterstützt wird. Ausführliche Informationen zur Syntax finden Sie in der [Dokumentation](https://docs.rs/regex/1/regex/#syntax) zur Kastenrate. Wenn das Muster ungültig ist, verwendet die App ihr Standardservererkennungsmuster. Verwenden Sie eine erste Aufnahmegruppe für die erkannte URL oder den erkannten Port. Die App liest die Erfassungsgruppe `1`: * Wenn es sich bei der Aufnahme um eine URL (`http://...` oder `https://...`) handelt, wird die URL verwendet. * Wenn die Aufnahme nur eine Portnummer ist (z. B `3000`. ), konvertiert die App sie in `http://localhost:3000`. ### `auto_open_in_browser` Wenn `auto_open_in_browser` ja `true`, öffnet die App die erkannte Ausführungs-URL im integrierten Browser. Wenn dieses Feld nicht angegeben wird, lautet `true`der effektive Standardwert . ## Konfigurieren des Automatisierungsverhaltens Festlegen von Automatisierungsoptionen unter `automation`: * `automation.auto_issue_session` (`boolean`) steuert, ob die App automatisch eine Sitzung mit Problemkontext startet. Wenn nicht angegeben, lautet `true`der effektive Standardwert . * `automation.remote_control` (`boolean`) steuert, ob über die GitHub Weboberfläche oder GitHub Mobileüber die Weboberfläche auf Sitzungen zugegriffen werden kann. Wenn nicht angegeben, lautet `false`der effektive Standardwert . Wenn Ihr Copilot Arbeitsplatz von einer Organisation stammt, muss die entsprechende Richtlinie "Lokale Store-Sitzungen in der Cloud" auf "Anzeigen und Steuern" festgelegt werden, damit die Remotesteuerung verfügbar ist. Unternehmensverwaltete `remoteControl` Einstellungen können auch dann `automation.remote_control``true`die Remotesteuerung weiter einschränken. Weitere Informationen findest du unter [Informationen zur Remotesteuerung von GitHub Copilot CLI Sitzungen](/de/copilot/concepts/agents/copilot-cli/about-remote-control) und [Unternehmensverwaltete Einstellungen](/de/copilot/reference/enterprise-administrators/enterprise-managed-settings). ## Laufzeitumgebungsvariablen für Skripts Skripts werden mit diesen von der App bereitgestellten Umgebungsvariablen ausgeführt: | Variable | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------- | | `COPILOT_WORKSPACE_NAME` | Name des aktuellen Arbeitsbereichs. | | `COPILOT_WORKSPACE_PATH` | Absoluter Pfad zum Arbeitsbereich. | | `COPILOT_ROOT_PATH` | Absoluter Pfad zum Auschecken des Projektstamms. | | `COPILOT_DEFAULT_BRANCH` | Project Standardverzweigung. | | `COPILOT_PORT` | App WebSocket-Port für den aktuellen Arbeitsbereichskontext. | | `COPILOT_SCRIPT_TRIGGER` | Trigger, der das Skript gestartet hat (nur für ausgelöste Skripts festgelegt). | | `GH_TOKEN` | Token für das ausgewählte GitHub Konto. | | `GH_HOST` | Host für das ausgewählte GitHub Konto. | | `COPILOT_GH_ACCOUNT_*` | Host- und kontospezifische Token für jedes angemeldete Konto, einschließlich des ausgewählten Kontos. | Für jede `COPILOT_GH_ACCOUNT_*` Variable schreibt die App den Host und die Anmeldung in Kleinbuchstaben, lässt ASCII-Buchstaben und Ziffern unverändert und ersetzt jedes andere UTF-8-Byte durch seinen Hexadezimalwert in Großbuchstaben, umgeben von Unterstrichen. Der Variablename verwendet das Format `COPILOT_GH_ACCOUNT__`. Das Token für `alice` "On `github.com` " lautet `COPILOT_GH_ACCOUNT_github_2E_com_alice`beispielsweise , und das Token für `user` "Ein" `ghe-example.com` lautet `COPILOT_GH_ACCOUNT_ghe_2D_example_2E_com_user`. ## Legacykompatibilität Aus Gründen der Abwärtskompatibilität kann die App weiterhin die ältere objektbasierte `scripts` Form analysieren: ```yaml copy scripts: setup: bun install run: bun run dev archive: rm -rf node_modules ``` In diesem Legacy-Shape: * `setup` ordnet einem Skript mit dem Create-Trigger zu. * `archive` ordnet einem Skript mit dem Archivtrigger zu. * `run` ordnet manuellen Skripteinträgen zu und kann entweder eine einzelne Befehlszeichenfolge oder eine Liste von `{ name, command }` Objekten sein.