Cada projeto aponta para um repositório. As configurações desse repositório determinam como o Coroid interage com seu modelo de ramificação.
Você os encontra nas configurações do projeto.
Sincronizado ou apenas local
O modo do repositório define se o Coroid pode gravar em GitHub ou GitLab.
- Sincronizado (o padrão): o Coroid envia a ramificação de cada tarefa e abre pull requests contra sua ramificação base.
- Apenas local: o Coroid clona e extrai do repositório, mas nunca grava nele. Sem envios, sem ramificações remotas, sem pull requests, comentários, revisões, execuções de verificação ou webhooks, sem mesclagens e sem execução de pipelines. Ramificações, commits, revisões, QA e pré-visualizações ocorrem inteiramente dentro do Coroid.
Sincronizado
- Extrai dados do GitHub
- Envia branches e abre pull requests
Apenas local
- Extrai dados do GitHub
- Nunca envia, comenta ou abre pull requests
- Você obtém as branches diretamente do git do próprio Coroid
Escolha o modo ao criar o projeto e altere-o nas configurações do projeto. Um projeto apenas local exibe Apenas local ao lado do nome do repositório.
O modo apenas local é a forma segura de testar o Coroid em um repositório real. Tarefas e planos são executados até a fase de revisão. Onde estaria um pull request, a revisão exibe Armazenado no Coroid e uma ação, Iniciar sincronização. A aprovação requer um projeto sincronizado, pois a aprovação mescla na sua ramificação base; dentro de um plano, as tarefas ainda são agrupadas na ramificação do plano no Coroid. A cópia que o Coroid mantém da sua ramificação base permanece idêntica à remota, portanto nada chega lá sem que você tenha aberto um pull request.
Para visualizar o trabalho em sua máquina, abra Clonar e exportar nas configurações do repositório, crie um token de acesso e obtenha as ramificações do Coroid a partir de seu próprio Git:
git remote add coroid https://coroid@git.coroid.ai/git/<project-id>.git
git fetch coroidIniciar sincronização altera o projeto para o modo Sincronizado. A partir de então, o novo trabalho é enviado e gera pull requests. O trabalho já armazenado no Coroid permanece onde está: abra seu pull request a partir da página de revisão (Criar pull request para uma tarefa, Abrir pull request para um plano). Reverter para o modo Apenas local entra em vigor imediatamente.
Nada no modo Apenas local depende do escopo do seu token: o Coroid recusa qualquer gravação no próprio repositório, independentemente do que a conexão permitir. O modo acompanha as configurações de ramificação do projeto em Portabilidade de configurações.
Ramo base
O Coroid cria ramos a partir do seu ramo base e abre pull requests de volta para ele. Por padrão, esse é o ramo padrão do repositório.
Altere-o se você fizer merge em outro lugar — um ramo develop de lançamento ou um ramo de integração de longa duração. Cometer esse erro é o equívoco de configuração mais comum, resultando em pull requests direcionados a um ramo que ninguém revisa.
Quando o ramo de destino muda
Um plano registra o commit do ramo base a partir do qual ele começa. Se o ramo base mudar antes do merge do pull request do plano, o Coroid suspende o merge; veja Quando o ramo base é atualizado. Essa configuração define o que acontece em seguida:
- Pausar para revisão (padrão) — alguém analisa os novos commits e, então, aceita-os ou solicita ao Coroid que faça o merge e reavalie-os.
- Fazer merge e reavaliar — o Coroid mescla as alterações no ramo do plano e executa novamente os agentes de desenvolvimento, QA e revisão, sem aguardar intervenção humana. Isso consome horas de uso de agentes. Se o merge ou a reavaliação falharem, a decisão volta para uma pessoa.
De qualquer forma, nada é mesclado até que o plano seja verificado em relação ao ramo base atual ou até que uma pessoa aprove as diferenças. Essa configuração faz parte das definições de ramo do projeto, portanto, acompanha o projeto em portabilidade de configurações.
Ramos de trabalho
Cada tarefa opera em sua própria ramificação. As ramificações são criadas por tarefa e enviadas quando o trabalho está pronto (em um projeto local apenas, elas ficam no Coroid). Assim, duas tarefas executadas simultaneamente nunca compartilham a mesma ramificação e não conseguem visualizar o trabalho em progresso uma da outra.
Nada jamais é commitado diretamente no seu ramo base. Isso não é uma configuração; é uma característica do funcionamento do Coroid.
Um branch por tarefa. Duas tarefas nunca compartilham um branch.
Suas revisões e verificações de status exigidas são aplicadas sem alterações.
Você mescla em main
Proteção de ramos
Suas regras de proteção de ramos existentes permanecem inalteradas. O Coroid abre um pull request comum, portanto revisões obrigatórias, verificações de status e restrições de quem pode fazer merge funcionam exatamente como para sua equipe.
Se suas regras exigirem commit assinado ou uma verificação de status específica que o Coroid não consiga gerar, o pull request será aberto e permanecerá sem poder ser mesclado — isso ocorre devido às suas regras, não por falha do Coroid.
Limpeza
Os ramos de trabalho concluído podem ser removidos após o pull request ser mesclado ou fechado. Se você utilizar nomes de ramos para auditoria ou ferramentas de release, verifique essa opção antes de habilitá-la.
Alterando a conexão
Se a conexão do repositório subjacente mudar — um token rotacionado, um aplicativo reinstalado ou um repositório renomeado — o projeto preservará sua identidade e histórico. Reapontá-lo para a nova conexão, em vez de criar um novo projeto, evita a perda de contexto, configurações e trabalhos anteriores.
Configurações do pipeline de lançamentos
O branch base determina onde o Coroid abre pull requests. A implantação utiliza um projeto separado. Lançamento Configuração de lançamento: um ambiente, sua política de prontidão e, opcionalmente, uma referência de pipeline GitLab ou ações do GitHub. A referência deve apontar para o commit fixado do lançamento antes que o Coroid solicite a execução. Configure uma credencial de retorno de chamada no escopo do ambiente para que o pipeline possa informar seu resultado; a conexão com o repositório por si só não comprova o que foi implantado. Pipelines externos podem relatar eventos sem que o Coroid habilite o envio de comandos.