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.

Em telas maiores, a tela de Repositórios mostra os repositórios conectados de cada provedor em cards ou numa lista compacta: alterne entre os dois na barra de ferramentas. Ela abre do jeito que você deixou, com a mesma aba de provedor, a mesma visualização e o mesmo filtro de visibilidade, mesmo depois de fechar o navegador. No celular, a tela mantém a sua apresentação própria.

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.
• Grupos de concorrência exatamente como o GitHub executa, para workflows e jobs (um espaço de nomes por repositório): um run ou job do grupo por vez, cancel-in-progress, e queue — single mantém só o mais novo esperando, max até 100 atendidos na ordem de chegada.
• 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.
• Chaves de pausa em dois níveis — desative um único workflow barulhento, ou vire a chave geral do repositório para pausar todo o CI dele. Um pipeline pausado para de disparar (pushes, agendamentos, disparo manual), mas continua listado com seu histórico; as duas chaves vêm ligadas por padrão.

Workflows portáveis#

Um workflow escrito para o GitHub roda aqui sem mudanças. Algumas coisas valem saber:

• secrets.GITHUB_TOKEN já vem pronto, como no GitHub: é o token de instalação do repositório conectado, e ${{ github.token }} dá o mesmo valor. Você nunca declara esse segredo — nenhum segredo seu pode se chamar GITHUB_*.
• EQUANTIC_SPACE vale true em todo step. O resto do ambiente imita o provedor de propósito (GITHUB_ACTIONS=true, GITHUB_SERVER_URL=https://github.com), para que as actions reais se comportem exatamente como no GitHub — então essa é a única variável que um workflow pode ler para saber onde está rodando, quando algum step precisa mesmo ser diferente.
• actions/cache funciona sobre o nosso próprio serviço de cache, nas duas versões de protocolo que a action conhece. cache-from: type=gha num build Docker usa o mesmo armazenamento.
• Seu checkout fica onde o GitHub coloca: $GITHUB_WORKSPACE é /home/runner/work/<repo>/<repo>, e o diretório pai é $RUNNER_WORKSPACE, que pertence ao seu job. Então um step escreve ao lado do checkout como os workflows fazem — git clone … ../<repo>.wiki para ler a wiki de um repositório, um build de saída fora da árvore — e ${{ runner.workspace }} é esse pai, igual a um runner hospedado.
• Os três tipos de action rodam: JavaScript, composite e Docker. Uma action Docker sobe como container ao lado do seu job, com o workspace montado onde o GitHub monta (/github/workspace) — uma imagem docker:// é baixada, e uma action que traz Dockerfile é construída na hora. Só runs.pre-entrypoint e runs.post-entrypoint não rodam, e o step avisa no log em vez de pular calado.
• shell: é o shell que você pediu: bash, sh, python, pwsh ou um template próprio como bash -e {0}. Um interpretador que a imagem não tem falha o step dizendo o nome dele, em vez de rodar seu script como outra coisa. defaults.run vale no nível do workflow e do job, tanto para shell quanto para working-directory.
• github.event é o payload entregue, então github.event.pull_request.number, github.event.head_commit.message e contains(github.event.pull_request.labels.*.name, …) leem como no GitHub. github.event_name diz o que aconteceu de verdade, e os inputs de um disparo manual chegam em inputs e em github.event.inputs.

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.