Repositórios & CI/CD

Conectar repositórios e rodar pipelines nos eQuantic Runners.

Conectar repositórios#

Use o GitHub App (recomendado) para permissões granulares geridas pela organização, com tokens de instalação de curta duração. O Azure DevOps agora é suportado: conecte uma organização com um Personal Access Token e escolha os repositórios (org/project/repo) — os webhooks (Service Hooks) são configurados automaticamente. O GitLab também está disponível: conecte-o com um Personal Access Token — gitlab.com ou sua própria instância self-hosted — e escolha os projetos (incluindo subgrupos profundamente aninhados); os webhooks são configurados automaticamente. O Bitbucket também é um provedor de primeira classe: conecte um workspace do Bitbucket com um app password ou um token de API da Atlassian (com o e-mail da sua conta) e escolha os repositórios (workspace/repo); os webhooks são configurados automaticamente. GitHub, GitLab, Bitbucket e Azure DevOps são todos totalmente suportados.

Pipelines#

A plataforma interpreta seus YAMLs do GitHub Actions, do Azure Pipelines (azure-pipelines.yml), do GitLab CI (.gitlab-ci.yml) e do Bitbucket Pipelines (bitbucket-pipelines.yml) e executa os jobs nos eQuantic Runners. Recursos:

• Grafo de jobs derivado das dependências needs:, com matrix builds expandindo em nós paralelos.
• Tasks reais do Azure Pipelines nos steps task:, resolvidas a partir da sua própria organização (incluindo tasks do marketplace); tasks disponíveis apenas em PowerShell e service connections ainda não são suportadas.
• Logs ao vivo por step, com re-run de tudo / só falhas / job individual.
• Editor visual de steps (arrastar e soltar) e modo de edição avançada do YAML.
• Aprovação manual antes de deploy de produção (quórum N-de-M) e environments protegidos.
• Cache configurável e secrets/variáveis por repositório, com referências a variáveis de serviços.

Pull requests#

Com um repositório conectado (GitHub, GitLab, Bitbucket ou Azure DevOps), você pode optar por gerenciar os Pull Requests dele dentro da eQuantic, em vez de no provedor — um opt-in por repositório. O código continua sempre no provedor; a eQuantic nunca hospeda o git.

• Opt-in na aba Pull requests — ative os PRs gerenciados pela eQuantic, ou continue usando os PRs do provedor (o padrão).
• Criação de PRs — escolha o branch de origem → destino, título e descrição; cada PR recebe uma numeração própria por repositório.
• Lista com estados — open / draft / merged / closed, com filtros.
• Visualização do diff — a eQuantic calcula o diff por conta própria (three-dot, contra o merge-base, como nas UIs dos provedores) e o armazena: a tela de detalhes mostra um resumo (arquivos alterados, +adições −remoções) e hunks unificados por arquivo, com números de linha exatos. Arquivos binários e diffs muito grandes são sinalizados em vez de renderizados; novos pushes no branch de origem atualizam o diff automaticamente via webhook do repositório.
• Revisão de código no diff — comente em qualquer linha do diff: as threads ficam ancoradas na linha exata, com respostas e resolução/reabertura. Quando novos commits chegam, as threads existentes nunca se perdem — são sinalizadas como desatualizadas e agrupadas por arquivo.
• Comentários bloqueantes — um comentário de revisão pode ser marcado como bloqueante; comentários bloqueantes não resolvidos ganham destaque no PR (banner e indicador na lista), e só o autor do comentário pode resolvê-los.
• Aprovações e conversa — revisores aprovam ou solicitam alterações (um veredito ativo por revisor; o autor do PR não pode revisar o próprio PR), com contadores de aprovações/alterações no PR e na lista — além de um feed de comentários gerais no PR, ao lado das threads de linha.
• Proteção de branch — nas configurações do repositório, defina regras por padrão de branch (main, release/*): número mínimo de aprovações, histórico linear, exigir que o branch esteja atualizado com o destino, descartar aprovações antigas quando chegam novos commits e se comentários bloqueantes não resolvidos vetam o merge — além das estratégias de merge permitidas e da estratégia padrão.
• Merge dentro da eQuantic — quando todas as condições passam (aprovações, nenhuma solicitação de alterações, nenhum comentário bloqueante não resolvido, regras de proteção), o merge do PR pode ser feito com merge commit, squash ou rebase. A eQuantic executa o merge por conta própria e envia o resultado ao provedor via push — nunca pela API de merge do provedor, nunca com force-push. Enquanto o merge estiver bloqueado, o PR lista exatamente o que falta; um PR também pode ser fechado sem merge.
• Fila de merge — em vez de fazer o merge diretamente, um PR pode entrar na fila de merge do branch de destino. A fila processa as entradas em ordem: cada uma é testada contra o estado atual do destino — um branch que ficou para trás não precisa ser atualizado manualmente, e entrar na fila é permitido mesmo com o branch desatualizado — e, se todas as condições continuarem valendo no momento do merge, a eQuantic executa o merge e faz o push do resultado. Um conflito ou uma condição não atendida derruba a entrada da fila com o motivo, e a próxima segue em frente; entradas em espera podem sair da fila, e o painel da fila na aba Pull requests mostra as posições e o status ao vivo.
• Checks de CI — execuções de pipeline nos commits do PR reportam seu status nativamente no PR: um check por workflow, por commit — pendente, sucesso ou falha — exibido no painel de merge. Uma regra de proteção de branch também pode exigir checks: o merge do PR só acontece quando todos os checks reportados passaram — um check com falha ou ainda em execução bloqueia o merge, assim como a ausência de qualquer check reportado (um check exigido nunca passa em silêncio). A mesma exigência vale também para as entradas da fila de merge.

Ambientes de preview#

Cada Pull Request aberto pode ganhar um ambiente de preview efêmero — um serviço isolado, construído a partir do branch do PR, com URL própria (pr-N.preview.<domínio-de-deploy>).

• Configuração por repositório na aba Previews: o toggle de auto-preview, o Space de destino e um ambiente base opcional, cujas variáveis são clonadas em cada preview.
• Ciclo de vida automático — PR aberto → ambiente provisionado; novos pushes → redeploy; merge/fechamento → teardown. O card mostra o status ao vivo (building → ready / failed), a URL, branch/commit e autor.
• Modo manual — a aba lista os PRs abertos sem preview, com criação em um clique; previews existentes podem ser reconstruídos ou destruídos pelo menu do card.
• A URL do preview é publicada como comentário no PR e mantida atualizada.