GitHub se conecta por meio do Coroid Aplicativo GitHub ou por um token de acesso pessoal. Configure-o em Configurações → Conexões → Controle de versão.
Aplicativo ou token
Prefira o aplicativo. Ele concede acesso por repositório em vez de por usuário, continua funcionando mesmo quando a pessoa que o configurou sai da empresa e recebe eventos de webhook sem necessidade de polling.
Use um token quando a instalação do aplicativo exigir aprovação de administrador da organização que você não consiga obter.
| Aplicativo GitHub | Token de acesso pessoal | |
|---|---|---|
| Escopo de acesso | Por repositório | Tudo o que o usuário pode visualizar |
| Continua funcionando após a saída do instalador | Sim | Não |
| Eventos de webhook | Sim | Polling |
| Atribuição | O aplicativo | O proprietário do token |
Instalar o aplicativo
Escolha GitHub em Configurações → Conexões → Controle de versão e siga o fluxo de instalação. O GitHub pergunta quais repositórios devem ter acesso concedido; você pode alterar isso posteriormente nas configurações próprias do GitHub.
Se um repositório não aparecer ao criar um projeto, é quase certo que o aplicativo não teve acesso concedido a esse repositório específico — essa é de longe a causa mais comum.
Usar um token
Crie um token clássico com o escopo repo , ou um token refinado com permissões de leitura e escrita em conteúdo e pull requests, e depois cole-o nas configurações de controle de versão.
Os tokens são criptografados em repouso, nunca são retornados pelo API e nunca são incluídos nas exportações de configurações.
Problemas do GitHub
A mesma conexão permite importar problemas como tarefas. Veja Importar tarefas.
Eventos que viram tarefas
Com o aplicativo, uma automação de eventos pode enviar um pull request, um novo problema ou um comentário mencionando Coroid para Qualificação. Veja Gatilhos e destinos.
As tarefas qualificadas provenientes desses eventos só começam automaticamente quando seu autor tem permissão de escrita, manutenção ou administração no repositório. O Coroid solicita ao GitHub para cada evento. No caso de um pull request, o autor é a pessoa que o abriu, não quem o rotulou ou fez merge. Tarefas de outras pessoas são criadas e aguardam que alguém as inicie. Um comentário que menciona Coroid só conta quando seu autor tem permissão de escrita.
Revisar pull requests
Com o aplicativo, o Coroid verifica e revisa pull requests abertos por pessoas e outras ferramentas, não apenas os próprios do Coroid. O Controle de Qualidade do Coroid executa as verificações do projeto e publica a verificação de Controle de Qualidade do Coroid. A Revisão do Coroid publica uma revisão com comentários nas linhas questionadas e uma verificação chamada Revisão do Coroid. Ambas são configuradas em Controle de Qualidade, na seção Pull requests. Veja Pull requests.
O que o Coroid faz no seu repositório
- lê o código para entendê-lo e modificá-lo
- cria um branch por tarefa
- envia esse branch e abre um pull request contra o seu branch base
Ele nunca commita no seu branch padrão nem faz merge sozinho. O merge ocorre somente quando uma pessoa faz merge do pull request no GitHub ou clica em Aprovar e mesclar no Coroid.
Um projeto configurado como Apenas local realiza apenas a primeira dessas etapas e nada mais: o Coroid lê e extrai dados, mantendo branches, revisões e verificações dentro do Coroid. Ele não envia, abre ou comenta em pull requests, nem publica execuções de verificação, mesmo quando o aplicativo ou token permitiriam isso. Veja Sincronizado ou apenas local.
Suas regras de proteção de branch, verificações obrigatórias e revisão permanecem inalteradas. Aprovar e mesclar também faz merge através do pull request, portanto as mesmas regras determinam se a operação será bem-sucedida. Veja Fazer merge.
Segurança
A Segurança usa o aplicativo para publicar a verificação Coroid Security , e, com permissões opcionais, para importar os próprios alertas de segurança do GitHub e verificar filas de merge. Veja Permissões do GitHub e a verificação de Segurança do Coroid.