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 ver |
| 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 que mencione Coroid para a etapa de Qualificação. Veja Gatilhos e destinos.
O trabalho qualificado a partir desses eventos só começa 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. O trabalho gerado por outras pessoas é criado e aguarda que alguém o inicie. Um comentário que mencione 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 no 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 uma branch por tarefa
- envia essa branch e abre um pull request contra sua branch base
Ele nunca commita na sua 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 mergear no Coroid.
Um projeto configurado como Apenas local realiza apenas a primeira dessas ações e nada mais: O Coroid lê e extrai dados, e mantém 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 que o aplicativo ou token permitam. Veja Sincronizado ou apenas local.
Suas regras de proteção de branch, verificações obrigatórias e revisão permanecem inalteradas. Aprovar e mergear também faz merge através do pull request, portanto as mesmas regras determinam se o processo será bem-sucedido. Veja Fazer merge.