Builds e supply chain

O Coda Cloud trata o código-fonte de cada cliente como não confiável. Por isso o build roda isolado, passa por análises de segurança e só gera imagens assinadas, com proveniência ligada ao commit. Só essas imagens podem ser implantadas.

Conectar o repositório

1. Em Integrações da organização, Owner ou Admin conecta o GitHub ou o GitLab. A plataforma pede só leitura de conteúdo e de metadados e gestão de webhooks.
2. Na aba Origem da aplicação, Owner, Admin ou Developer escolhe o repositório, o branch e o diretório raiz, a estratégia de build (Auto, Dockerfile ou Buildpacks) e pode ligar o deploy automático.

O repositório precisa ser visível pela conexão da sua organização; um repositório que a conexão não enxerga é recusado como "não encontrado".

GitHub

A conexão instala o GitHub App do Coda Cloud na conta ou organização escolhida e pede a sua autorização. A plataforma confere que a instalação é sua, usa só as permissões dessa instalação e descarta o seu token de usuário: nenhum token do GitHub fica guardado. Cada checkout recebe um token de instalação válido por no máximo 1 hora e restrito ao repositório do build, com leitura de conteúdo.

Os webhooks são assinados com o segredo do App e conferidos antes de qualquer outra coisa. Se você remover a instalação ou o acesso a um repositório no GitHub, a conexão fica Desconectada ou a origem mostra Sem acesso ao repositório, e o build manual é recusado até você conceder o acesso de novo. Conexões criadas antes da verificação de instalação aparecem com Reconectar.

GitLab

A conexão com o gitlab.com usa OAuth com os escopos read_api e read_repository. Uma autorização com api ou write_repository é recusada. Só o refresh token fica no cofre da plataforma; ele é renovado a cada uso.

Como o GitLab não permite criar webhooks com escopo de leitura, você registra o webhook: ao conectar, o portal mostra uma única vez a URL (/api/v1/webhooks/gitlab) e o token secreto. No projeto do GitLab, em Settings › Webhooks, cole a URL, o token em Secret token e marque Push events. GitLab auto-hospedado não é suportado.

Quando um build acontece

• A cada push no branch vinculado.
• Manualmente, pelo botão Novo build, para um commit do branch (Owner, Admin e Developer).

Estágios

Cada build executa, em ordem, os estágios abaixo. O portal mostra a linha do tempo com estado, duração e evidências de cada um:

Estágio	O que faz
Checkout	Baixa o commit em ambiente isolado.
Secret scan	Procura credenciais vazadas no código (Gitleaks).
SAST	Análise estática de segurança (Semgrep).
Build	Gera a imagem com Buildpacks/BuildKit rootless.
SBOM	Gera a lista de componentes da imagem (Syft), disponível para download.
Vulnerabilidades	Analisa as dependências (Trivy/OSV).
Assinatura e proveniência	Assina a imagem e registra de qual commit e build ela veio (Cosign/Tekton Chains).
Push	Publica a imagem no registry da plataforma, por digest.

Ambiente de build isolado

O build roda em sandbox em um pool de máquinas próprio, sem socket de contêiner do host, sem privilégios, sem credenciais de infraestrutura e sem as variáveis e segredos de runtime da aplicação. A credencial do checkout existe só na etapa de checkout, que não executa o seu código; as etapas que leem ou executam o código não têm token nem segredo algum.

Saída de rede (allowlist)

Durante o build, o acesso à internet passa por um proxy com uma lista de domínios permitidos da plataforma: registries de pacotes (npm, PyPI, NuGet, Go, Maven Central, Gradle, RubyGems, crates.io), repositórios de pacotes Debian, Ubuntu e Alpine, os hosts Git (github.com, gitlab.com) e os registries de imagens base (as imagens públicas também vêm pelo cache do registry da plataforma). Redes internas, o Control Plane e APIs de metadata ficam sempre bloqueados.

Um acesso a domínio fora da lista recebe 403 e aparece como evidência Acesso negado no detalhe do build, com o domínio. Se o seu build precisa de outro domínio público (por exemplo, um CDN de binários), abra um chamado no suporte com o domínio e o motivo; a lista é global e revisada pela plataforma.

Logs ao vivo, cancelar e repetir

O detalhe do build mostra o log da etapa em execução ao vivo (com segredos e tokens mascarados); se a conexão cair, a tela passa a atualizar a cada 3 segundos. Builds na fila ou em execução podem ser cancelados (Developer ou acima): os minutos contam até o cancelamento. Builds FAILED, BLOCKED ou CANCELED podem ser repetidos, o que cria um novo build do mesmo commit. Falhas de infraestrutura (por exemplo, a máquina de build removida) são repetidas automaticamente até duas vezes.

Bloqueios

O build termina como BLOCKED, sem push e sem deploy, quando:

• um segredo é encontrado no código; ou
• há vulnerabilidade crítica sem exceção válida.

A justificativa e as evidências ficam no detalhe do build.

Exceções de vulnerabilidade

Owner e Admin podem registrar uma exceção para uma vulnerabilidade específica em uma aplicação, com justificativa e validade de no máximo 90 dias. Exceções vencidas deixam de valer.

Deploy automático

Com o deploy automático ligado, todo build SUCCEEDED cria um novo deploy da aplicação com a imagem por digest. Builds BLOCKED ou FAILED nunca geram deploy.

Admissão de imagens

Todo deploy, manual ou automático, passa pela verificação de admissão. A imagem precisa:

1. ser referenciada por digest;
2. estar no registry da plataforma;
3. ter assinatura e proveniência da identidade de build da plataforma.

Caso contrário, o deploy é recusado e o portal mostra o motivo. Imagens externas passam pelo mesmo processo: são importadas para o registry, analisadas (SBOM e vulnerabilidades) e assinadas pela plataforma antes de poderem ser implantadas. O próprio runtime repete a verificação como segunda barreira, então um workload criado por fora da API também é recusado.

O registry não permite sobrescrever um digest publicado, registra push e pull, e cada organização acessa só os próprios repositórios.

Limites de build do plano

Cada plano define o tempo máximo de um build, a CPU e a memória de cada etapa e quantos builds rodam ao mesmo tempo na organização; os demais aguardam na fila, com a posição no detalhe do build. A plataforma também tem uma capacidade global de builds simultâneos: quando ela está cheia, o build mostra Aguardando capacidade de build. Um build que espera mais de 60 minutos na fila falha com queue_timeout, sem contar minutos.

Plano	Tempo máximo	CPU	Memória	Simultâneos
Starter	15 min	1 vCPU	2 GiB	1
Pro	30 min	2 vCPU	4 GiB	2
Business	45 min	2 vCPU	6 GiB	4
Enterprise	60 min	3 vCPU	8 GiB	8

Os valores efetivos da sua organização aparecem na página do plano.

Minutos de build

Cada build concluído, com sucesso, falha, bloqueio ou cancelamento depois de começar, conta minutos de build arredondados para cima. A cota mensal depende do plano; com ela esgotada, novos builds são recusados ("Minutos de build do mês esgotados") e os pushes são registrados na auditoria sem gerar build. Veja Planos, recursos e limites.

Cache de build

Cada aplicação tem um cache de build próprio, guardado num projeto do registry exclusivo da organização. Builds do branch vinculado leem e gravam o cache; builds de pull request só leem. O cache não conta na cota de armazenamento e é apagado depois de 14 dias sem uso. O detalhe do build mostra se o cache foi restaurado. Um build com segredo detectado nunca grava o cache.

Fora do escopo atual

Provedores Git auto-hospedados, monorepos com várias aplicações por push, build de Dockerfile arbitrário com privilégios e cache de build compartilhado entre organizações.