Fügen Sie Regeln und Pfade für eine Vorschau des Build-Kontexts ein. Der Textvergleich liest kein Repository und startet keinen Docker-Build.
Läuft lokal in deinem BrowserDas linke Feld nimmt den Inhalt einer .dockerignore-Datei auf, das rechte die möglichen Pfade, einer pro Zeile, wie sie innerhalb der Wurzel des Build-Kontexts liegen. Nach einem Klick auf Build-Kontext testen erhält jeder Pfad ein Urteil: ausgeschlossen oder eingeschlossen, zusammen mit der entscheidenden Regel und einem Hinweis, wenn der Treffer über einen übergeordneten Ordner kam. Die rechte Spalte zeigt außerdem die normalisierte Regelliste — die Zeilen, die Docker tatsächlich liest — und einen Bericht zu den üblichen Risiken im Build-Kontext.
.dockerignore sagt dem Docker-Client, welche Dateien aus dem Build-Kontext herausbleiben, also aus dem Baum, der an den Daemon geht und den ADD und COPY sehen. Diese Seite liest nur diesen Text: Sie öffnet kein Repository, durchsucht keinen echten Kontextordner und startet keinen Build. Alles Folgende beschreibt die Regeln, die diese Seite anwendet und die der Implementierung von Docker folgen.
Der Leser entfernt eine UTF-8-BOM in der ersten Zeile, ignoriert Zeilen, deren erstes Zeichen # ist, und überspringt leere Zeilen; ein # erst nach Leerzeichen ist ein Muster, kein Kommentar. Jede verbleibende Zeile wird getrimmt, ein führendes ! markiert eine Ausnahme, und der Rest wird wie ein Pfad bereinigt: ./x wird zu x, a//b zu a/b, a/../b zu b, foo/ zu foo. Danach wird ein führender Schrägstrich entfernt, /foo und foo sind also dasselbe Muster. Eine Zeile, die nur ! enthält, ist ein Fehler: Docker bricht mit »illegal exclusion pattern« ab.
Muster, die diese Bereinigung nicht überstehen, werden gemeldet, bevor ein Build startet: eine nicht geschlossene [-Klasse, ein ] oder - an falscher Stelle in einer Klasse oder ein Muster, das mit einem Backslash endet. Die Seite nennt Zeilennummer und Text, statt die Datei stillschweigend zu wiederholen.
Jeder Kandidat wird von oben nach unten mit den Mustern verglichen, und das letzte passende Muster entscheidet; eine spätere Ausnahme kann eine frühere Ausnahme also rückgängig machen. Das Muster wird gegen den vollständigen Pfad relativ zur Kontextwurzel geprüft: *.md erfasst Markdown-Dateien in der Wurzel, **/*.md jede Tiefe. Ein einzelnes * oder ? überquert keinen Schrägstrich, ** überquert Verzeichnisse (a/**/b passt auch auf a/b, und **/foo auch auf ein foo in der Wurzel), [0-9] und [^a-z] sind Zeichenklassen, und ein Backslash maskiert das nächste Zeichen.
Ein Muster entscheidet auch für alles innerhalb eines Ordners, auf den es passt — deshalb schließt node_modules auch node_modules/react/index.js aus; die Ergebnisse sagen das mit dem Hinweis auf den übergeordneten Ordner. Weil nur die letzte passende Regel zählt, holt eine !-Zeile, die erreicht wird, während nichts ausgeschlossen ist, nichts zurück; der Bericht listet solche wirkungslosen Zeilen auf.
Die Urteile sind Texturteile. Die Seite durchsucht niemals Ihr Repository, eine Datei, die nicht in der Kandidatenliste steht, wird also nie geprüft, und die Liste ist eine Stichprobe statt des echten Kontexts. Docker-Versionen unterscheiden sich leicht darin, wie Kontexte übertragen und gefiltert werden; ein ungewöhnliches Muster prüfen Sie besser mit dem Client nach, mit dem Sie bauen.
.dockerignore bestimmt nur, was der Client an den Daemon sendet. Es erzeugt selbst keine Image-Layer, beeinflusst keine Laufzeit-Mounts und ändert nicht, was ein COPY oder ADD kopiert: Eine Datei, die im Kontext bleibt, kann kopiert werden, und eine ausgeschlossene Datei lässt ein COPY scheitern, wenn der Dockerfile sie erwartet. Prüfen Sie also auch die Kopierpfade.