Testador de regras .dockerignore

Cole regras e caminhos para revisar o contexto de build esperado. A análise de texto não lê seu repositório nem executa Docker.

Funciona localmente no seu navegador
Esta ferramenta processa todos os dados localmente no seu navegador.
Regras e caminhos candidatosPadrões e caminhos são avaliados localmente como texto; o VoriTools nunca lê seu repositório ou contexto Docker.

Como testar regras .dockerignore com caminhos candidatos

A caixa à esquerda recebe o conteúdo de um arquivo .dockerignore e a da direita os caminhos candidatos, um por linha, como aparecem dentro da raiz do contexto de build. Ao clicar em Testar contexto de build, cada caminho recebe um veredito: excluído ou incluído, junto com a regra que decidiu e uma observação quando a correspondência veio de uma pasta acima. A coluna da direita também mostra a lista normalizada de regras, ou seja, as linhas que o Docker lê de fato, e um relatório dos riscos comuns do contexto.

O .dockerignore diz ao cliente Docker quais arquivos ficam fora do contexto de build, a árvore que é enviada ao daemon e que ADD e COPY enxergam. Esta página lê apenas esse texto: não abre seu repositório, não percorre uma pasta de contexto real e não executa build. O texto abaixo descreve as regras de correspondência aplicadas aqui, que seguem a implementação usada pelo Docker.

  1. Cole o arquivo na caixa Regras .dockerignore, um padrão por linha. Linha cujo primeiro caractere é # é comentário; ! transforma a linha em exceção que reinclui arquivos.
  2. Liste em Caminhos candidatos os caminhos a conferir, um por linha, escritos como aparecem dentro do contexto: src/index.js, node_modules/react/index.js, .env.
  3. Clique em Testar contexto de build. Cada candidato recebe o rótulo excluído ou incluído e a regra que decidiu é nomeada — por exemplo «excluído · corresponde: node_modules (pasta superior)» quando a correspondência vem de uma pasta acima do arquivo.
  4. Leia a caixa .dockerignore normalizado: comentários e linhas vazias saem, ./x, a//b, a/../b e uma barra no fim são limpos e uma barra no início é removida; o que aparece é o que o Docker lê.
  5. Veja a lista de resultados para os riscos comuns — .git, node_modules, .env e chaves privadas, regras que capturam tudo, regras que não casaram com nenhum candidato — e confirme um padrão incomum com a versão do Docker que você usa, porque a lista de candidatos é apenas uma amostra do contexto real.

Como o Docker lê o arquivo, como os padrões casam e o que esta página não vê

Como o arquivo é lido

O leitor remove o BOM UTF-8 da primeira linha, ignora linhas cujo primeiro caractere é # e pula as vazias; um # que só aparece depois de espaços é padrão, não comentário. Cada linha restante é aparada, um ! inicial marca exceção e o resto é limpo como caminho: ./x vira x, a//b vira a/b, a/../b vira b, foo/ vira foo. Depois, uma barra inicial é removida, então /foo e foo são o mesmo padrão. Uma linha só com ! é erro: o Docker para com «illegal exclusion pattern».

Padrões que não sobrevivem a essa limpeza são avisados antes de qualquer build: classe [ sem fechar, ] ou - em posição errada dentro da classe, ou padrão terminando em barra invertida. A página informa o número da linha e o texto exato em vez de repetir o arquivo em silêncio.

Como um padrão casa com um caminho

Cada candidato é comparado aos padrões de cima para baixo e o último que casa decide, por isso uma exceção posterior pode desfazer uma exclusão anterior. O padrão é comparado ao caminho completo em relação à raiz do contexto: *.md cobre os markdown da raiz e **/*.md cobre qualquer profundidade. Um * ou ? não atravessa a barra /, ** atravessa diretórios (a/**/b também casa com a/b, e **/foo também com um foo na raiz), [0-9] e [^a-z] são classes de caracteres e a barra invertida escapa o próximo caractere.

Um padrão também decide por tudo que está dentro de uma pasta com que ele casa: por isso node_modules exclui node_modules/react/index.js, e os resultados dizem isso com a nota de pasta superior. Como só a última regra que casa conta, uma linha ! alcançada sem nada excluído não traz nada de volta, e o relatório lista essas linhas inúteis.

O que esta página não vê

Os vereditos são de texto. A página nunca percorre seu repositório, então um arquivo que não esteja na lista de candidatos não é examinado, e a lista é uma amostra, não o contexto real. Versões do Docker diferem um pouco na transferência e no filtro de contextos, então vale reconferir um padrão incomum com o cliente que você usa.

O .dockerignore só define o que o cliente envia ao daemon. Não cria camadas de imagem por si só, não afeta montagens em tempo de execução e não muda o que um COPY ou ADD copia: um arquivo que permanece no contexto pode ser copiado, e um arquivo excluído faz o COPY falhar quando o Dockerfile conta com ele. Confira também os caminhos de cópia.

Ferramentas recentes: