Imagem de container do ADR Guard

O ADR Guard é publicado como imagem OCI multi-plataforma em dois registries:

GitHub Container Registry (GHCR): ghcr.io/rodri-oliveira-dev/adr-guard
Docker Hub: docker.io/rodrigodotnet/adr-guard

Os dois registries recebem o mesmo build de release para linux/amd64 e linux/arm64.

Baixar a imagem

GHCR:

docker pull ghcr.io/rodri-oliveira-dev/adr-guard:latest

Docker Hub:

docker pull rodrigodotnet/adr-guard:latest

Validar ADRs

Monte o repositório em /workspace, que é o diretório de trabalho da imagem:

docker run --rm \
  -v "$PWD:/workspace:ro" \
  ghcr.io/rodri-oliveira-dev/adr-guard:latest \
  check docs/adr

A validação pode usar um volume somente leitura porque check não altera arquivos do repositório.

A GitHub Action reutilizável aplica restrições adicionais sobre essa imagem: filesystem raiz somente leitura, workspace do consumidor somente leitura no check, remoção de todas as capabilities Linux, no-new-privileges e rede desabilitada. Consulte o modelo de segurança da GitHub Action.

Gerar o índice de ADRs

index escreve no repositório montado. Em Linux e macOS, usar o UID/GID do host evita diferenças de ownership nos arquivos gerados:

docker run --rm \
  --user "$(id -u):$(id -g)" \
  -v "$PWD:/workspace" \
  ghcr.io/rodri-oliveira-dev/adr-guard:latest \
  index docs/adr

A imagem já executa como usuário não-root por padrão. O --user explícito acima serve apenas para alinhar o ownership de volumes graváveis do host quando necessário.

`new` offline e templates personalizados (disponível a partir da v1.1.0)

As imagens de container publicadas incluem new e suporte a templates personalizados desde a v1.1.0. Use uma imagem estável publicada; não é necessário compilar uma branch de feature. Para consumir a major móvel use :1, ou fixe uma tag SemVer exata/digest quando precisar de reprodutibilidade:

mkdir -p docs/adr
docker run --rm --user "$(id -u):$(id -g)" \
  -v "$PWD:/workspace" ghcr.io/rodri-oliveira-dev/adr-guard:1 \
  new docs/adr --title "Adotar Redis" --template minimal --culture pt-BR

docker run --rm --user "$(id -u):$(id -g)" \
  -v "$PWD:/workspace" ghcr.io/rodri-oliveira-dev/adr-guard:1 \
  new docs/adr --title "Adotar Cache" \
  --template-file docs/examples/templates/team.pt-BR.md --culture pt-BR

docker run --rm -v "$PWD:/workspace:ro" \
  ghcr.io/rodri-oliveira-dev/adr-guard:1 check docs/adr
docker run --rm --user "$(id -u):$(id -g)" \
  -v "$PWD:/workspace" ghcr.io/rodri-oliveira-dev/adr-guard:1 \
  index docs/adr

new é offline e não usa segredos: não forneça OPENAI_API_KEY nem outras credenciais de provider. O diretório precisa existir e ser gravável pelo usuário do container; o template é resolvido em relação ao diretório de trabalho /workspace e precisa ser legível. Use volume somente leitura com new --preview/--dry-run, que exibem o Markdown proposto sem gravar. Uma execução real de new não atualiza o índice automaticamente. Imagens v1.0.x anteriores não incluem essas opções.

Consulte criação offline, exemplos validados e exit codes, placeholders personalizados e draft com template/privacidade. A GitHub Action @v1 publicada suporta check, index e review opt-in; new e draft assistido por IA continuam sendo fluxos de CLI/container direto.

Criação assistida por IA

As credenciais dos providers devem ser fornecidas em runtime por variáveis de ambiente. Elas nunca são incorporadas à imagem.

Exemplo com OpenAI:

docker run --rm \
  --user "$(id -u):$(id -g)" \
  -e OPENAI_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/rodri-oliveira-dev/adr-guard:latest \
  draft docs/adr \
  --title "Adotar um message broker" \
  --context "Precisamos de integração assíncrona." \
  --provider openai \
  --model <modelo-openai>

As mesmas regras de variáveis de ambiente documentadas para a .NET Tool valem para Anthropic, Gemini e providers OpenAI-compatible.

Controles de supply chain

O caminho do container é protegido por controles independentes:

Hadolint é um quality gate obrigatório do Dockerfile no CI;
Dependabot monitora as imagens-base .NET referenciadas pelo Dockerfile;
o CI faz build e smoke tests da imagem antes que uma release possa executar;
o Trivy analisa a imagem gerada no CI em busca de vulnerabilidades corrigíveis HIGH e CRITICAL em pacotes do sistema operacional e bibliotecas, falhando o workflow quando encontra alguma;
a imagem de runtime usa a variante chiseled do .NET e executa como usuário não-root;
imagens de release recebem metadados OCI de origem, documentação, autor, licença, versão e revisão;
o BuildKit publica uma attestation de SBOM e uma attestation de provenance em mode=max para cada release multi-plataforma;
o workflow de release verifica a presença dos manifests linux/amd64, linux/arm64 e dos manifests de attestation tanto no GHCR quanto no Docker Hub.

O SBOM e a provenance são attestations OCI associadas ao índice da imagem publicada, e não arquivos embutidos no filesystem de runtime.

Inspecionar uma release

Para inspecionar o manifest multi-plataforma e as attestations associadas:

docker buildx imagetools inspect \
  ghcr.io/rodri-oliveira-dev/adr-guard:1.2.3

Para usar uma referência imutável, resolva o digest e fixe a imagem:

ghcr.io/rodri-oliveira-dev/adr-guard@sha256:<digest>

Fluxo de release

As imagens de container só são publicadas depois que o workflow de CI do commit validado na main termina com sucesso. Em seguida, o workflow de release resolve a mesma versão SemVer usada pelo pacote NuGet, cria/verifica a Git tag, publica a imagem multi-plataforma no GHCR e no Docker Hub, valida os manifests e as attestations publicados e somente então conclui a GitHub Release.