# Configuração do repositório para o GitHub aplicativo Copilot Defina instruções, scripts e comportamento de automação específicos do repositório para o GitHub Copilot app. Use `.github/github-app.yml` em seu repositório para definir como o GitHub Copilot app deve se comportar para esse projeto. Você também pode editar essas configurações de projeto na interface do usuário do aplicativo. Se `.github/github-app.yml` já existir, as alterações de interface do usuário serão gravadas de volta nesse arquivo. Se ele ainda não existir, você poderá criá-lo a partir das configurações atuais do projeto no aplicativo. ## Sobre o local do arquivo de configuração Crie o arquivo em: ```text copy .github/github-app.yml ``` O aplicativo também dá suporte ao nome de arquivo herdado `.github/copilot-desktop.yml` para compatibilidade com versões anteriores. Para obter as etapas de personalização baseadas em interface do usuário, consulte [Personalizando a aplicativo Copilot do GitHub](/pt/enterprise-cloud@latest/copilot/how-tos/github-copilot-app/customize-github-copilot-app). ## Examinar e confiar na configuração Quando o aplicativo detecta uma configuração do repositório, ele não aplica instruções de repositório, scripts ou outras configurações do arquivo até que você examine e aceite a configuração. Isso protege você contra a execução de comandos ou a aplicação de configurações que foram adicionadas por outro colaborador. As configurações que você cria ou atualiza por meio da interface do usuário do aplicativo são confiáveis automaticamente. > \[!WARNING] > Antes de aceitar uma configuração de repositório, examine cada comando configurado e as dependências que ele executa. Os scripts e seus processos filho recebem as GitHub credenciais descritas posteriormente neste artigo, portanto, nunca configure-os para registrar ou persistir essas variáveis de ambiente. Se o arquivo for alterado fora do aplicativo, incluindo alterações no espaço em branco ou comentários, você deverá examinar e aceitar a configuração atualizada antes que o aplicativo a aplique. Até que você aceite a versão atual, o aplicativo continua a usar as configurações de projeto que foram configuradas anteriormente no aplicativo. ## Configuração de exemplo ```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 ``` ## Configurar instruções e scripts ### `instructions` Use `instructions` para adicionar diretrizes específicas do repositório ao prompt do sistema para sessões no projeto. Se você também configurar instruções globais no aplicativo, as instruções globais serão aplicadas primeiro, seguidas pelas instruções do projeto. ### `scripts` Use `scripts` para definir comandos que aparecem no aplicativo e podem ser executados manualmente ou em gatilhos específicos. Cada item de script dá suporte a: * `name` (`string`): Nome de exibição na interface do usuário. * `command` (`string`): Comando a ser executado. * `triggers` (`string[]`opcional): eventos que executam automaticamente o script. Scripts sem `triggers` são manuais. ### Valores de gatilho Use valores de gatilho canônicos em seu arquivo: * `session.create` * `session.archive` O aplicativo também aceita esses aliases herdados ao analisar arquivos existentes: * `workspace.create` (alias for `session.create`) * `workspace.archive` (alias for `session.archive`) Quando um script disparado é executado, `COPILOT_SCRIPT_TRIGGER` é definido como o valor canônico: * `session.create` * `session.archive` ## Configurar a detecção de servidor e o comportamento do navegador ### `server_ready_pattern` `server_ready_pattern` é uma expressão regular usada para detectar quando um script de execução iniciou um servidor. Os padrões usam a sintaxe compatível com o crate do `regex` Rust. Para obter detalhes de sintaxe, consulte [Sintaxe](https://docs.rs/regex/1/regex/#syntax) na documentação do crate. Se o padrão for inválido, o aplicativo usará seu padrão de detecção de servidor padrão. Use um primeiro grupo de captura para a URL ou porta detectada. O aplicativo lê o grupo `1`de captura: * Se a captura for uma URL (`http://...` ou `https://...`), a URL será usada. * Se a captura for apenas um número de porta (por exemplo `3000`), o aplicativo a converterá `http://localhost:3000`em . ### `auto_open_in_browser` Se `auto_open_in_browser` estiver `true`, o aplicativo abrirá a URL de execução detectada no navegador integrado. Se esse campo for omitido, o padrão efetivo será `true`. ## Configurar o comportamento da automação Defina as opções de automação em `automation`: * `automation.auto_issue_session` (`boolean`) controla se o aplicativo inicia automaticamente uma sessão com contexto de problema. Se omitido, o padrão efetivo será `true`. * `automation.remote_control` (`boolean`) controla se as sessões podem ser acessadas na interface da GitHub Web ou GitHub Mobile. Se omitido, o padrão efetivo será `false`. Se o seu Copilot assento for proveniente de uma organização, a política aplicável "Armazenar sessões locais na nuvem" deverá ser definida como "Exibir e controlar" para que o controle remoto esteja disponível. As configurações gerenciadas pela `remoteControl` empresa podem restringir ainda mais o controle remoto mesmo quando `automation.remote_control` for `true`. Para obter mais informações, consulte [Sobre o controle remoto de GitHub Copilot CLI sessões](/pt/enterprise-cloud@latest/copilot/concepts/agents/copilot-cli/about-remote-control) e [Configurações gerenciadas pela empresa](/pt/enterprise-cloud@latest/copilot/reference/enterprise-administrators/enterprise-managed-settings). ## Variáveis de ambiente de runtime para scripts Os scripts são executados com essas variáveis de ambiente fornecidas pelo aplicativo: | Variable | Descrição | | ------------------------ | ------------------------------------------------------------------------------------------- | | `COPILOT_WORKSPACE_NAME` | Nome do workspace atual. | | `COPILOT_WORKSPACE_PATH` | Caminho absoluto para o workspace. | | `COPILOT_ROOT_PATH` | Caminho absoluto para o check-out raiz do projeto. | | `COPILOT_DEFAULT_BRANCH` | Project branch padrão. | | `COPILOT_PORT` | Porta WebSocket do aplicativo para o contexto atual do workspace. | | `COPILOT_SCRIPT_TRIGGER` | Gatilho que iniciou o script (definido apenas para scripts disparados). | | `GH_TOKEN` | Token para a conta selecionada GitHub . | | `GH_HOST` | Hospedar para a conta selecionada GitHub . | | `COPILOT_GH_ACCOUNT_*` | Tokens específicos de host e conta para cada conta assinada, incluindo a conta selecionada. | Para cada `COPILOT_GH_ACCOUNT_*` variável, o aplicativo reduz o host e o logon, deixa as letras e dígitos ASCII inalterados e substitui todos os outros bytes UTF-8 por seu valor hexadecimal maiúsculo cercado por sublinhados. O nome da variável usa o formato `COPILOT_GH_ACCOUNT__`. Por exemplo, o token para `alice` ativado `github.com` é `COPILOT_GH_ACCOUNT_github_2E_com_alice`, e o token para `user` ativado `ghe-example.com` é `COPILOT_GH_ACCOUNT_ghe_2D_example_2E_com_user`. ## Compatibilidade herdada Para compatibilidade com versões anteriores, o aplicativo ainda pode analisar a forma mais antiga baseada em `scripts` objeto: ```yaml copy scripts: setup: bun install run: bun run dev archive: rm -rf node_modules ``` Nesta forma herdada: * `setup` mapeia para um script com o gatilho create. * `archive` mapeia para um script com o gatilho de arquivo morto. * `run` mapeia para entradas de script manuais e pode ser uma única cadeia de caracteres de comando ou uma lista de `{ name, command }` objetos.