Documentação

Configurações de repositório e ramificações

Qual ramo o Coroid utiliza, onde os pull requests são criados e como os ramos são nomeados.

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

CoroidGitHub
  • Extrai dados do GitHub
  • Envia branches e abre pull requests

Apenas local

CoroidGitHub
  • Extrai dados do GitHub
  • Nunca envia, comenta ou abre pull requests
  • Você obtém as branches diretamente do git do próprio Coroid
O modo local permite testar o Coroid em um repositório real: ele lê dados de GitHub e mantém todas as branches, commits e revisões dentro do Coroid. Comece a sincronizar quando desejar criar pull requests.

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 coroid

Iniciar 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

Cada tarefa trabalha em seu próprio branch a partir do seu branch base. O trabalho retorna apenas como um pull request, através da proteção de branch que você já possui.

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.