Collez règles et chemins pour examiner le contexte de build attendu. L’analyse textuelle ne lit pas le dépôt et ne lance aucun build Docker.
Fonctionne localement dans votre navigateurLe champ de gauche reçoit le contenu d’un fichier .dockerignore, celui de droite les chemins candidats, un par ligne, tels qu’ils apparaissent dans la racine du contexte de construction. Après un clic sur Tester le contexte de build, chaque chemin reçoit un verdict : exclu ou inclus, avec la règle qui a décidé et une mention lorsque la correspondance vient d’un dossier parent. La colonne de droite affiche aussi la liste normalisée des règles — les lignes que Docker lit vraiment — et un rapport sur les risques habituels du contexte.
Le fichier .dockerignore indique au client Docker quels fichiers sortent du contexte de construction, l’arborescence envoyée au démon et visible par ADD et COPY. Cette page ne lit que ce texte : elle n’ouvre pas votre dépôt, ne parcourt aucun dossier de contexte réel et ne lance aucune construction. Ce qui suit décrit les règles appliquées ici, qui suivent l’implémentation utilisée par Docker.
Le lecteur retire le BOM UTF-8 de la première ligne, ignore les lignes dont le premier caractère est # et saute les lignes vides ; un # qui n’apparaît qu’après des espaces est un motif, pas un commentaire. Chaque ligne restante est rognée, un ! initial marque une exception, et le reste est nettoyé comme un chemin : ./x devient x, a//b devient a/b, a/../b devient b, foo/ devient foo. Une barre initiale est ensuite retirée : /foo et foo sont donc le même motif. Une ligne réduite à ! est une erreur : Docker s’arrête sur « illegal exclusion pattern ».
Les motifs qui ne survivent pas à ce nettoyage sont signalés avant toute construction : une classe [ non fermée, un ] ou un - mal placés dans une classe, ou un motif terminé par une barre oblique inverse. La page indique le numéro de ligne et le texte fautif au lieu de répéter le fichier en silence.
Chaque candidat est comparé aux motifs de haut en bas et le dernier motif correspondant décide : une exception plus bas peut donc annuler une exclusion plus haut. Le motif est comparé au chemin complet par rapport à la racine du contexte : *.md couvre les fichiers markdown de la racine, **/*.md toutes les profondeurs. Un * ou un ? ne franchit jamais la barre oblique, ** franchit les dossiers (a/**/b correspond aussi à a/b, et **/foo à un foo à la racine), [0-9] et [^a-z] sont des classes de caractères et la barre oblique inverse échappe le caractère suivant.
Un motif décide aussi pour tout ce qui se trouve dans un dossier auquel il correspond — c’est pourquoi node_modules exclut node_modules/react/index.js ; les résultats l’indiquent avec la mention du dossier parent. Comme seule la dernière règle correspondante compte, une ligne ! atteinte alors que rien n’est exclu ne réintègre rien, et le rapport liste ces lignes sans effet.
Les verdicts portent sur du texte. La page ne parcourt jamais votre dépôt : un fichier absent de la liste de candidats n’est jamais examiné, et cette liste est un échantillon, pas le contexte réel. Les versions de Docker diffèrent légèrement dans le transfert et le filtrage des contextes ; mieux vaut revérifier un motif inhabituel avec le client que vous utilisez.
.dockerignore ne détermine que ce que le client envoie au démon. Il ne crée pas de couches d’image à lui seul, n’affecte pas les montages à l’exécution et ne change pas ce qu’un COPY ou un ADD copie : un fichier resté dans le contexte peut être copié, et un fichier exclu fait échouer un COPY lorsque le Dockerfile compte sur lui. Vérifiez aussi les chemins de copie.