Repositórios & CI/CD

Ligar repositórios e correr pipelines nos eQuantic Runners.

Ligar 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 já é suportado: ligue 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 já está disponível: ligue-o com um Personal Access Token — gitlab.com ou a 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 fornecedor de primeira classe: ligue 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 os 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. Funcionalidades:

• Grafo de jobs derivado das dependências needs:, com matrix builds a expandir em nós paralelos.
• Tasks reais do Azure Pipelines nos steps task:, resolvidas a partir da própria organização (incluindo tasks do marketplace); as tasks disponíveis apenas em PowerShell e as service connections ainda não são suportadas.
• Registos ao vivo por step, com re-run de tudo / só falhas / job individual.
• Editor visual de steps (arrastar e largar) 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 ligado (GitHub, GitLab, Bitbucket ou Azure DevOps), pode optar por gerir os respetivos Pull Requests dentro da eQuantic, em vez de no fornecedor — um opt-in por repositório. O código fica sempre no fornecedor; a eQuantic nunca aloja o git.

• Opt-in no separador Pull requests — ative os PRs geridos pela eQuantic, ou continue a usar os PRs do fornecedor (a predefiniçã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.
• Vista do diff — a eQuantic calcula o diff por si própria (three-dot, contra o merge-base, como nas UIs dos fornecedores) e armazena-o: o ecrã de detalhe mostra um resumo (ficheiros alterados, +adições −remoções) e hunks unificados por ficheiro, com números de linha exatos. Os ficheiros binários e os diffs muito grandes são assinalados em vez de renderizados; novos pushes no branch de origem atualizam o diff automaticamente através do 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 chegam novos commits, as threads existentes nunca se perdem — são assinaladas como desatualizadas e agrupadas por ficheiro.
• Comentários bloqueantes — um comentário de revisão pode ser marcado como bloqueante; os comentários bloqueantes por resolver ganham destaque no PR (banner e indicador na lista), e só o autor do comentário os pode resolver.
• Aprovações e conversa — os revisores aprovam ou pedem alterações (um veredito ativo por revisor; o autor do PR não pode rever o próprio PR), com contadores de aprovações/alterações no PR e na lista — e ainda um feed de comentários gerais no PR, a par das threads de linha.
• Proteção de branch — nas definiçõ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 face ao destino, descartar aprovações antigas quando chegam novos commits e se os comentários bloqueantes por resolver vetam o merge — além das estratégias de merge permitidas e da estratégia predefinida.
• Merge dentro da eQuantic — quando todas as condições passam (aprovações, nenhum pedido de alterações, nenhum comentário bloqueante por resolver, regras de proteção), o merge do PR pode ser feito com merge commit, squash ou rebase. A eQuantic executa o merge por si própria e envia o resultado para o fornecedor por push — nunca através da API de merge do fornecedor, 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 de imediato, um PR pode entrar na fila de merge do branch de destino. A fila processa as entradas por ordem: cada uma é testada contra o estado atual do destino — um branch que ficou para trás não precisa de ser atualizado manualmente, e entrar na fila é permitido mesmo com o branch desatualizado — e, se todas as condições continuarem a cumprir-se no momento do merge, a eQuantic executa o merge e faz push do resultado. Um conflito ou uma condição por cumprir retira a entrada da fila com o motivo, e a seguinte avança; as entradas em espera podem sair da fila, e o painel da fila no separador Pull requests mostra as posições e o estado ao vivo.
• Checks de CI — as execuções de pipeline nos commits do PR reportam o respetivo estado nativamente no PR: um check por workflow, por commit — pendente, sucesso ou falha — apresentado no painel de merge. Uma regra de proteção de branch pode ainda exigir checks: o merge do PR só acontece quando todos os checks reportados passaram — um check falhado ou ainda em execução bloqueia o merge, tal como a ausência de qualquer check reportado (um check exigido nunca passa em silêncio). A mesma exigência aplica-se igualmente às entradas da fila de merge.

Ambientes de preview#

Cada Pull Request aberto pode ter 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 no separador Previews: o toggle de auto-preview, o Space de destino e um ambiente base opcional, cujas variáveis são clonadas para cada preview.
• Ciclo de vida automático — PR aberto → ambiente provisionado; novos pushes → redeploy; merge/fecho → teardown. O cartão mostra o estado ao vivo (building → ready / failed), a URL, branch/commit e autor.
• Modo manual — o separador lista os PRs abertos sem preview, com criação num clique; os previews existentes podem ser reconstruídos ou destruídos a partir do menu do cartão.
• A URL do preview é publicada como comentário no PR e mantida atualizada.