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.

Em ecrãs maiores, o ecrã de Repositórios mostra os repositórios ligados de cada fornecedor em cartões ou numa lista compacta: alterne entre os dois na barra de ferramentas. Abre tal como o deixou, com o mesmo separador de fornecedor, a mesma vista e o mesmo filtro de visibilidade, mesmo depois de fechar o navegador. No telemóvel, o ecrã mantém a sua apresentação própria.

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.
• Grupos de concorrência exatamente como o GitHub os executa, para workflows e jobs (um espaço de nomes por repositório): um run ou job do grupo de cada vez, cancel-in-progress, e queue — single mantém apenas o mais recente em espera, max até 100 atendidos por ordem de chegada.
• 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.
• Interruptores de pausa a dois níveis — desative um workflow ruidoso, ou desligue o interruptor geral do repositório para pausar todo o seu CI. Um pipeline em pausa deixa de disparar (pushes, agendamentos, dispatch manual), mas continua listado com o seu histórico; ambos os interruptores vêm ligados por predefinição.

Workflows portáveis#

Um workflow escrito para o GitHub corre aqui sem alterações. Há algumas coisas que vale a pena saber:

• secrets.GITHUB_TOKEN já vem preenchido, tal como no GitHub: é o token de instalação do repositório ligado, e ${{ github.token }} dá o mesmo valor. Nunca o declara — nenhum segredo seu pode chamar-se GITHUB_*.
• EQUANTIC_SPACE é true em todos os steps. O resto do ambiente imita o fornecedor de propósito (GITHUB_ACTIONS=true, GITHUB_SERVER_URL=https://github.com), para que as actions reais se comportem exactamente como no GitHub — fica a ser esta, por isso, a única variável que um workflow pode ler para saber onde está a correr, para o raro step que tenha mesmo de ser diferente.
• actions/cache funciona sobre o nosso serviço de cache, nas duas versões de protocolo que a action fala. cache-from: type=gha num build Docker usa o mesmo armazenamento.
• O seu checkout fica onde o GitHub o põe: $GITHUB_WORKSPACE é /home/runner/work/<repo>/<repo>, e a pasta pai é $RUNNER_WORKSPACE, que pertence ao seu job. Assim um step escreve ao lado do checkout como os workflows fazem — git clone … ../<repo>.wiki para ler a wiki de um repositório, um resultado de build fora da árvore — e ${{ runner.workspace }} é essa pasta pai, como num runner alojado.
• Os três tipos de action correm: JavaScript, composite e Docker. Uma action Docker arranca como contentor ao lado do seu job, com a workspace montada onde o GitHub a monta (/github/workspace) — uma imagem docker:// é descarregada, e uma action que traz Dockerfile é construída na altura. Apenas runs.pre-entrypoint e runs.post-entrypoint não correm, e o step di-lo no log em vez de os saltar em silêncio.
• shell: é a shell que 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 nomeando-o, em vez de correr o seu script como outra coisa. defaults.run aplica-se ao nível do workflow e do job, tanto para shell como para working-directory.
• github.event é o payload entregue, pelo que github.event.pull_request.number, github.event.head_commit.message e contains(github.event.pull_request.labels.*.name, …) leem-se como no GitHub. github.event_name diz o que realmente aconteceu, e os inputs de um disparo manual chegam em inputs e em github.event.inputs.

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.