GitHub & CI

Branches, pull requests e status de CI são cidadãos de primeira classe no Projectura: aparecem exatamente onde o trabalho acontece — dentro da tarefa. Você não troca de aba do navegador para saber se o pipeline passou; o Projectura traz isso para perto do que você está fazendo. Esta página mostra como conectar o GitHub, ligar repositórios ao projeto e ler tudo que passa a aparecer na tarefa.

Conectar o GitHub ao Projectura

A conexão é feita pelo GitHub App do Projectura — você o instala na sua conta ou organização e escolhe quais repositórios ele enxerga. É o jeito recomendado: funciona mesmo em organizações que restringem aplicativos, porque o App é o mecanismo que as orgs aprovam.

1. Abra o projeto que vai usar o GitHub e vá na aba Integrações.
2. Clique em Conectar repo → abre o painel Instalar GitHub App.
3. Escolha a conta ou organização onde instalar e selecione os repositórios (todos, ou só os que interessam). Você pode liberar mais repos depois.
4. Confirme. Você volta ao Projectura e a instalação fica amarrada à sua conta e à workspace ativa.

Pronto. Os repositórios da instalação passam a aparecer no seletor de repos com a etiqueta via App. Conectar um repo desses não cria nada extra no GitHub — os eventos já chegam todos pela instalação. Para adicionar, remover ou trocar os repos que o Projectura enxerga depois, use o mesmo botão (Gerenciar instalação), que te leva de volta à tela de seleção de repositórios.

Ligar repositórios ao projeto

A instalação dá ao Projectura acesso aos repos; ligar um repo ao projeto é o que faz os eventos daquele repositório aparecerem nas tarefas certas.

• No seletor de repos da aba Integrações, marque os repositórios que pertencem a este projeto.
• Multi-repo: um projeto pode ter vários repositórios ligados ao mesmo tempo. Útil quando o produto tem front-end, back-end e infra em repos diferentes — todos alimentam o mesmo board.
• O seletor mostra os repos via App primeiro. Se você já tinha repositórios conectados de um jeito mais antigo, eles continuam funcionando e aparecem na mesma lista; as duas fontes convivem sem você precisar migrar nada.

Um repositório que não está ligado a nenhum projeto é simplesmente ignorado — o Projectura não escreve nada a partir dele. Só o que você ligou de propósito reflete nas tarefas.

O que passa a aparecer na tarefa

Com repo ligado, três tipos de informação começam a fluir do GitHub para a tarefa, em tempo quase real (a tela se atualiza sozinha em poucos segundos, sem recarregar):

• Branch: no painel Dev da tarefa (trilha à direita, no detalhe) aparece o nome da branch vinculada, em fonte mono — ex.: feat/auth-pkce. Há um atalho para copiar a branch no menu de ações da tarefa.
• Status de CI: sempre que o CI roda naquela branch, o resultado aparece como um selo na tarefa (e no card do Kanban). Os significados de cada cor estão na próxima seção.
• Pull request: a aba PR & CI (no detalhe da tarefa) mostra o PR vinculado e o estado dele. A aba só fica disponível quando existe um PR ligado àquela tarefa.

O estado do PR aparece como um selo: OPEN (verde) — PR aberto, em andamento; MERGED (roxo) — PR já integrado; CLOSED (vermelho) — PR fechado sem merge.

Se o CI falhar, além do selo vermelho na tarefa você recebe um aviso na inbox — não precisa ficar vigiando o board para descobrir que algo quebrou.

Vínculo automático: branch ↔ tarefa e PR ↔ tarefa

O Projectura casa os eventos do GitHub com a tarefa certa por convenção de nome de branch.

1. No detalhe da tarefa, no painel Dev, informe o nome da branch que você vai usar para aquele trabalho — ex.: feat/login, fix/webhook-retry, chore/deps.
2. A partir daí, todo evento do GitHub daquela branch (CI rodando, CI concluído, PR aberto/mergeado) é vinculado àquela tarefa, no repositório e na workspace corretos.

Ou seja: o vínculo nasce do nome da branch que você declara na tarefa. Mantenha o nome da branch no Projectura igual ao do GitHub e o resto acontece sozinho — o status de CI e o PR aparecem sem nenhum passo manual a mais.

O que cada estado de CI significa

O selo de CI traduz o resultado do pipeline daquela branch em uma cor e um rótulo curtos. São quatro estados:

• ci:success — verde, com check. O pipeline rodou e passou.
• ci:failure — vermelho, com X. O pipeline rodou e falhou (algum job quebrou).
• ci:running — azul, com ícone girando. O CI está rodando agora; aguarde o resultado.
• ci:pending — amarelo, com relógio. O CI está na fila / pendente, ainda não começou.

Uma tarefa sem CI — recém-criada, ou cuja branch ainda não tem pipeline — simplesmente não mostra selo. O Projectura não inventa um "pendente" falso: ausência de selo significa "ainda não há informação de CI", não "está tudo certo".

O guard de "Concluída" quando o CI está vermelho

Este é o ponto onde o CI deixa de ser só um aviso e passa a proteger o seu fluxo: uma tarefa com CI falhando não pode ir para Concluída.

• No Kanban, arrastar um card com ci:failure para a coluna Concluída é bloqueado — o card volta e aparece um aviso. Cards nesse estado também ganham uma borda vermelha à esquerda para ficar óbvio o que está travando.
• Na lista, no detalhe da tarefa e até no widget de timer, tentar marcar a tarefa como concluída com o CI vermelho mostra a mensagem de que o CI falhou — corrija o PR antes de concluir.

A lógica é a mesma em todos os lugares: enquanto o CI estiver ci:failure, o caminho para "Concluída" fica fechado. Corrija o que quebrou, deixe o pipeline ficar ci:success, e a transição volta a ser permitida — sem precisar mexer em nenhuma configuração.

Próximos passos