hadolint
v2.12.0
Eine intelligentere Dockerfile -Verluste, mit der Sie Best Practice Docker -Bilder erstellen können. Der Linter analysiert die Dockerfile in einen AST und führt Regeln zusätzlich zum AST durch. Es steht auf den Schultern von Shellcheck, um den Bash -Code in RUN auszufahren.
Schauen Sie sich die Online -Version auf hadolint.github.io/hadolint an 
Sie können hadolint vor Ort ausführen, um Ihre Dockerfile abzugeben.
hadolint < Dockerfile >
hadolint --ignore DL3003 --ignore DL3006 < Dockerfile > # exclude specific rules
hadolint --trusted-registry my-company.com:500 < Dockerfile > # Warn when using untrusted FROM images Docker kommt zur Rettung und bietet einen einfachen Weg, wie man hadolint auf den meisten Plattformen betreibt. Überfassen Sie einfach Ihre Dockerfile zu docker run :
docker run --rm -i hadolint/hadolint < Dockerfile
# OR
docker run --rm -i ghcr.io/hadolint/hadolint < Dockerfileoder mit Podman:
podman run --rm -i docker.io/hadolint/hadolint < Dockerfile
# OR
podman run --rm -i ghcr.io/hadolint/hadolint < Dockerfileoder verwenden Windows PowerShell:
cat .Dockerfile | docker run -- rm - i hadolint / hadolint Sie können vorgefertigte Binärdateien für OSX, Windows und Linux von der neuesten Versionsseite herunterladen. Wenn dies jedoch nicht für Sie funktioniert, greifen Sie bitte auf den Container (Docker), brew oder Quelleninstallation zurück.
Auf OSX können Sie Brew verwenden, um hadolint zu installieren.
brew install hadolint Unter Windows können Sie hadolint -Installation verwenden.
scoop install hadolint Bei der Installation von Verteilungen, die nix installiert haben, können Sie das hadolint Paket verwenden, um Ad-hoc-Shells auszuführen oder hadolint dauerhaft in Ihre Umgebung zu installieren.
Wie bereits erwähnt, ist hadolint als Containerbild erhältlich:
docker pull hadolint/hadolint
# OR
docker pull ghcr.io/hadolint/hadolintWenn Sie einen Container mit Shell Access benötigen, verwenden Sie die Debian- oder Alpine -Varianten:
docker pull hadolint/hadolint:latest-debian
# OR
docker pull hadolint/hadolint:latest-alpine
# OR
docker pull ghcr.io/hadolint/hadolint:latest-debian
# OR
docker pull ghcr.io/hadolint/hadolint:latest-alpine Sie können auch hadolint vor Ort bauen. Sie benötigen Haskell und das Cabal Build -Werkzeug, um die Binärdatei zu bauen.
git clone https://github.com/hadolint/hadolint
&& cd hadolint
&& cabal configure
&& cabal build
&& cabal installWenn Sie möchten, dass die VS -Code -Hadolint -Erweiterung Hadolint in einem Container verwendet, können Sie das folgende Wrapper -Skript verwenden:
#! /bin/bash
dockerfile= " $1 "
shift
docker run --rm -i hadolint/hadolint hadolint " $@ " - < " $dockerfile " hadolint --help hadolint - Dockerfile Linter written in Haskell
Usage: hadolint [-v|--version] [-c|--config FILENAME] [DOCKERFILE...]
[--file-path-in-report FILEPATHINREPORT] [--no-fail]
[--no-color] [-V|--verbose] [-f|--format ARG] [--error RULECODE]
[--warning RULECODE] [--info RULECODE] [--style RULECODE]
[--ignore RULECODE]
[--trusted-registry REGISTRY (e.g. docker.io)]
[--require-label LABELSCHEMA (e.g. maintainer:text)]
[--strict-labels] [--disable-ignore-pragma]
[-t|--failure-threshold THRESHOLD]
Lint Dockerfile for errors and best practices
Available options:
-h,--help Show this help text
-v,--version Show version
-c,--config FILENAME Path to the configuration file
--file-path-in-report FILEPATHINREPORT
The file path referenced in the generated report.
This only applies for the 'checkstyle' format and is
useful when running Hadolint with Docker to set the
correct file path.
--no-fail Don't exit with a failure status code when any rule
is violated
--no-color Don't colorize output
-V,--verbose Enables verbose logging of hadolint's output to
stderr
-f,--format ARG The output format for the results [tty | json |
checkstyle | codeclimate | gitlab_codeclimate | gnu |
codacy | sonarqube | sarif] (default: tty)
--error RULECODE Make the rule `RULECODE` have the level `error`
--warning RULECODE Make the rule `RULECODE` have the level `warning`
--info RULECODE Make the rule `RULECODE` have the level `info`
--style RULECODE Make the rule `RULECODE` have the level `style`
--ignore RULECODE A rule to ignore. If present, the ignore list in the
config file is ignored
--trusted-registry REGISTRY (e.g. docker.io)
A docker registry to allow to appear in FROM
instructions
--require-label LABELSCHEMA (e.g. maintainer:text)
The option --require-label=label:format makes
Hadolint check that the label `label` conforms to
format requirement `format`
--strict-labels Do not permit labels other than specified in
`label-schema`
--disable-ignore-pragma Disable inline ignore pragmas `# hadolint
ignore=DLxxxx`
-t,--failure-threshold THRESHOLD
Exit with failure code only when rules with a
severity equal to or above THRESHOLD are violated.
Accepted values: [error | warning | info | style |
ignore | none] (default: info)
Konfigurationsdateien können global oder pro Projekt verwendet werden. Hadolint sucht nach Konfigurationsdateien an den folgenden Orten oder deren Plattformspezifische Äquivalente in dieser Reihenfolge und verwendet den ersten ausschließlich:
$PWD/.hadolint.yaml$XDG_CONFIG_HOME/hadolint.yaml$HOME/.config/hadolint.yaml$HOME/.hadolint/hadolint.yaml or $HOME/hadolint/config.yaml$HOME/.hadolint.yaml In Windows wird die %LOCALAPPDATA% -Umgebungsvariable anstelle von XDG_CONFIG_HOME verwendet. Konfigurationsdateien können entweder yaml oder yml -Erweiterungen haben.
hadolint Full yaml -Konfigurationsdateischema
failure-threshold : string # name of threshold level (error | warning | info | style | ignore | none)
format : string # Output format (tty | json | checkstyle | codeclimate | gitlab_codeclimate | gnu | codacy)
ignored : [string] # list of rules
label-schema : # See Linting Labels below for specific label-schema details
author : string # Your name
contact : string # email address
created : timestamp # rfc3339 datetime
version : string # semver
documentation : string # url
git-revision : string # hash
license : string # spdx
no-color : boolean # true | false
no-fail : boolean # true | false
override :
error : [string] # list of rules
warning : [string] # list of rules
info : [string] # list of rules
style : [string] # list of rules
strict-labels : boolean # true | false
disable-ignore-pragma : boolean # true | false
trustedRegistries : string | [string] # registry or list of registries hadolint unterstützt die Angabe der ignorierten Regeln mithilfe einer Konfigurationsdatei. Die Konfigurationsdatei sollte im yaml -Format vorliegen. Dies ist eine gültige Konfigurationsdatei als Beispiel:
ignored :
- DL3000
- SC1010 Darüber hinaus kann hadolint Sie warnen, wenn Bilder aus nicht trustedRegistries Repositorys in DockerFiles verwendet werden.
ignored :
- DL3000
- SC1010
trustedRegistries :
- docker.io
- my-company.com:5000
- " *.gcr.io "Wenn Sie die Schwere bestimmter Regeln außer Kraft setzen möchten, können Sie dies auch tun:
override :
error :
- DL3001
- DL3002
warning :
- DL3042
- DL3033
info :
- DL3032
style :
- DL3015 failure-threshold mit dem Ausfallcode nur dann, wenn Regeln mit einem Schweregrad über den Schwellenwert verstoßen werden (verfügbar in v2.6.0+)
failure-threshold : info
override :
warning :
- DL3042
- DL3033
info :
- DL3032 Zusätzlich können Sie eine benutzerdefinierte Konfigurationsdatei in der Befehlszeile mit der Option --config übergeben
hadolint --config /path/to/config.yaml DockerfileVerwenden Sie den folgenden Befehl:
docker run --rm -i -v /your/path/to/hadolint.yaml:/.config/hadolint.yaml hadolint/hadolint < Dockerfile
# OR
docker run --rm -i -v /your/path/to/hadolint.yaml:/.config/hadolint.yaml ghcr.io/hadolint/hadolint < DockerfileZusätzlich zu Konfigurationsdateien kann Hadolint mit Umgebungsvariablen konfiguriert werden.
NO_COLOR=1 # Set or unset. See https://no-color.org
HADOLINT_NOFAIL=1 # Truthy value e.g. 1, true or yes
HADOLINT_VERBOSE=1 # Truthy value e.g. 1, true or yes
HADOLINT_FORMAT=json # Output format (tty | json | checkstyle | codeclimate | gitlab_codeclimate | gnu | codacy | sarif )
HADOLINT_FAILURE_THRESHOLD=info # threshold level (error | warning | info | style | ignore | none)
HADOLINT_OVERRIDE_ERROR=DL3010,DL3020 # comma separated list of rule codes
HADOLINT_OVERRIDE_WARNING=DL3010,DL3020 # comma separated list of rule codes
HADOLINT_OVERRIDE_INFO=DL3010,DL3020 # comma separated list of rule codes
HADOLINT_OVERRIDE_STYLE=DL3010,DL3020 # comma separated list of rule codes
HADOLINT_IGNORE=DL3010,DL3020 # comma separated list of rule codes
HADOLINT_STRICT_LABELS=1 # Truthy value e.g. 1, true or yes
HADOLINT_DISABLE_IGNORE_PRAGMA=1 # Truthy value e.g. 1, true or yes
HADOLINT_TRUSTED_REGISTRIES=docker.io # comma separated list of registry urls
HADOLINT_REQUIRE_LABELS=maintainer:text # comma separated list of label schema items Bei Verwendung von Basisbildern mit nicht-posixen Shells als Standard (z. B. Windows-basierte Bilder) kann eine spezielle Pragma hadolint shell angeben, welche Shell das Basisbild verwendet, damit Hadolint automatisch alle Shell-spezifischen Regeln ignorieren kann.
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# hadolint shell=powershell
RUN Get-Process notepad | Stop-Process Es ist auch möglich, Regeln zu ignorieren, indem Sie einen speziellen Kommentar direkt über der Dockerfile -Erklärung hinzufügen, für die Sie eine Ausnahme machen möchten. Solche Kommentare sehen aus wie # hadolint ignore=DL3001,SC1081 . Zum Beispiel:
# hadolint ignore=DL3006
FROM ubuntu
# hadolint ignore=DL3003,SC1035
RUN cd /tmp && echo "hello!"Der Kommentar "Inline ignoriert" gilt nur für die folgende Erklärung.
Regeln können auch pro File mit dem globalen Ignorieren von Pragma ignoriert werden. Es funktioniert genauso wie Inline ignoriert, außer dass es für die gesamte Datei anstelle der nächsten Zeile gilt.
# hadolint global ignore=DL3003,DL3006,SC1035
FROM ubuntu
RUN cd /tmp && echo "foo" Hadolint kann überprüfen, ob bestimmte Etiketten vorhanden sind, und entsprechen einem vordefinierten Etikettsschema. Zunächst muss ein Etikettenschema entweder über die Befehlszeile definiert werden:
hadolint --require-label author:text --require-label version:semver Dockerfileoder über die Konfigurationsdatei:
label-schema :
author : text
contact : email
created : rfc3339
version : semver
documentation : url
git-revision : hash
license : spdx Der Wert eines Etiketts kann entweder text , url , semver , hash oder rfc3339 sein:
| Schema | Beschreibung |
|---|---|
| Text | Irgendetwas |
| RFC3339 | Eine Zeit, formatiert nach RFC 3339 |
| Semver | Eine semantische Version |
| URL | Ein URI, wie in RFC 3986 beschrieben |
| Hash | Entweder ein kurzer oder ein langer Git -Hash |
| SPDX | Eine SPDX -Lizenzkennung |
| Eine E -Mail -Adresse, die an RFC 5322 entspricht |
Standardmäßig ignoriert Hadolint jede Etikett, die im Etikettschema nicht angegeben ist. Um vor solchen zusätzlichen Etiketten zu warnen, schalten Sie strenge Beschriftungen mit der Befehlszeile ein:
hadolint --strict-labels --require-label version:semver Dockerfileoder die Konfigurationsdatei:
strict-labels : true Wenn strenge Beschriftungen aktiviert sind, aber kein Etikettenschema angegeben ist, warnt hadolint , ob ein Etikett vorhanden ist.
Es ist ein übliches Muster, den Wert einer Etikett nicht statisch, sondern zum Bauzeit dynamisch zu füllen, indem eine Variable verwendet wird:
FROM debian:buster
ARG VERSION= "du-jour"
LABEL version= "${VERSION}" Um dies zuzulassen, muss das Etikettenschema text als Wert für diese Etikett angeben:
label-schema :
version : text Um den größten Teil von hadolint zu erhalten, ist es nützlich, ihn als Check in Ihren CI oder in Ihren Redakteur oder als Vor-Commit-Haken zu integrieren, um Ihre Dockerfile beim Schreiben zu liefern. Siehe unsere Integrationsdokumente.
Eine unvollständige Liste der implementierten Regeln. Klicken Sie auf den Fehlercode, um detailliertere Informationen zu erhalten.
Regeln mit dem Präfix DL stammen von hadolint . Schauen Sie sich Rules.hs an. Hs, um die Umsetzung der Regeln zu finden.
Regeln mit dem SC -Präfix stammen von Shellcheck (nur die häufigsten Regeln sind aufgeführt, es gibt Dutzende mehr).
Bitte erstellen Sie ein Problem, wenn Sie eine Idee für eine gute Regel haben.
| Regel | Standardschwere | Beschreibung |
|---|---|---|
| DL1001 | Ignorieren | Bitte unterlassen Sie die Verwendung von Inline ignorieren Sie Pragmas # hadolint ignore=DLxxxx . |
| DL3000 | Fehler | Verwenden Sie absolute Workdir. |
| DL3001 | Info | Für einige Bash -Befehle macht es keinen Sinn, sie in einem Docker -Container wie SSH, VIM, Herunterfahren, Service, PS, kostenlos, top, töten, montieren, ifconfig auszuführen. |
| DL3002 | Warnung | Der letzte Benutzer sollte nicht root sein. |
| DL3003 | Warnung | Verwenden Sie Workdir, um in ein Verzeichnis zu wechseln. |
| DL3004 | Fehler | Verwenden Sie Sudo nicht, da dies zu unvorhersehbarem Verhalten führt. Verwenden Sie ein Tool wie Gosu, um die Wurzel durchzusetzen. |
| DL3006 | Warnung | Markieren Sie immer die Version eines Bildes explizit. |
| DL3007 | Warnung | Die Verwendung von neuesten ist anfällig für Fehler, wenn das Bild jemals aktualisiert wird. Pin der Version explizit in ein Release -Tag. |
| DL3008 | Warnung | PIN-Versionen in apt-get install . |
| DL3009 | Info | Löschen Sie die APT-Get-Listen, nachdem Sie etwas installiert haben. |
| DL3010 | Info | Verwenden Sie Add, um Archive in ein Bild zu extrahieren. |
| DL3011 | Fehler | Gültige UNIX -Ports reichen von 0 bis 65535. |
| DL3012 | Fehler | Mehrere HEALTHCHECK -Anweisungen. |
| DL3013 | Warnung | PIN -Versionen in PIP. |
| DL3014 | Warnung | Verwenden Sie den -y -Schalter. |
| DL3015 | Info | Vermeiden Sie zusätzliche Pakete, indem Sie --no-install-recommends angeben. |
| DL3016 | Warnung | PIN -Versionen in npm . |
| DL3018 | Warnung | PIN -Versionen in apk add . Anstelle von apk add <package> apk add <package>=<version> verwenden. |
| DL3019 | Info | Verwenden Sie den Switch --no-cache /var/cache/apk/* zu vermeiden, dass die --update verwendet werden muss. |
| DL3020 | Fehler | Verwenden Sie COPY anstelle von ADD für Dateien und Ordner. |
| DL3021 | Fehler | COPY mit mehr als 2 Argumenten, erfordert das letzte Argument, um mit / zu enden |
| DL3022 | Warnung | COPY --from sollte auf eine zuvor definierte FROM Alias verweisen |
| DL3023 | Fehler | COPY --from kann nicht auf seine eigene FROM Alias verweisen |
| DL3024 | Fehler | FROM Aliase (Künstlernamen) müssen eindeutig sein |
| DL3025 | Warnung | Verwenden Sie Argumente JSON Notation für CMD- und Einstiegspunkt -Argumente |
| DL3026 | Fehler | Verwenden Sie nur eine erlaubte Registrierung im FROM image |
| DL3027 | Warnung | Verwenden Sie apt , da es ein Endbenutzer-Tool sein soll. Verwenden Sie stattdessen apt-get oder apt-cache |
| DL3028 | Warnung | PIN -Versionen in Gem -Installation. Anstelle von gem install <gem> Verwenden Sie gem install <gem>:<version> |
| DL3029 | Warnung | Verwenden Sie nicht -Plattform -Flag mit. |
| DL3030 | Warnung | Verwenden Sie den Switch -y , um manuelle Eingänge zu vermeiden yum install -y <package> |
| DL3032 | Warnung | yum clean all Fabricy After Yum Command. |
| DL3033 | Warnung | Geben Sie die Version mit yum install -y <package>-<version> |
| DL3034 | Warnung | Nicht -interaktiver Schalter fehlt im Befehl zypper : zypper install -y |
| DL3035 | Warnung | Verwenden Sie nicht zypper dist-upgrade . |
| DL3036 | Warnung | zypper clean fehlt nach dem Gebrauch von Zypper. |
| DL3037 | Warnung | Geben Sie die Version mit zypper install -y <package>[=]<version> . |
| DL3038 | Warnung | Verwenden Sie den Switch -y , um die manuelle Eingabe dnf install -y <package> zu vermeiden, |
| DL3040 | Warnung | dnf clean all nach dem DNF -Befehl fehlen. |
| DL3041 | Warnung | Geben Sie die Version mit dnf install -y <package>-<version> |
| DL3042 | Warnung | Vermeiden Sie das Cache-Verzeichnis mit pip install --no-cache-dir <package> . |
| DL3043 | Fehler | ONBUILD , FROM oder MAINTAINER ausgelöst aus ONBUILD Unterricht ausgelöst. |
| DL3044 | Fehler | Beziehen Sie sich nicht auf eine Umgebungsvariable innerhalb derselben ENV -Anweisung, in der sie definiert ist. |
| DL3045 | Warnung | COPY in ein relatives Ziel ohne WORKDIR -Set. |
| DL3046 | Warnung | useradd ohne Flagge -l und hohe UID führt zu übermäßig großem Bild. |
| DL3047 | Info | wget ohne Flag --progress führt beim Herunterladen größerer Dateien zu übermäßig aufgeblähten Build -Protokollen. |
| DL3048 | Stil | Ungültiger Etikettschlüssel |
| DL3049 | Info | Label <label> fehlt. |
| DL3050 | Info | Überflüssige Etiketten vorhanden. |
| DL3051 | Warnung | Label <label> ist leer. |
| DL3052 | Warnung | Label <label> ist keine gültige URL. |
| DL3053 | Warnung | Label <label> ist kein gültiges Zeitformat - muss an RFC3339 entsprechen. |
| DL3054 | Warnung | Label <label> ist keine gültige SPDX -Lizenzkennung. |
| DL3055 | Warnung | Label <label> ist kein gültiger Git -Hash. |
| DL3056 | Warnung | Label <label> entspricht nicht der semantischen Versionierung. |
| DL3057 | Ignorieren | HEALTHCHECK fehlt. |
| DL3058 | Warnung | Label <label> ist kein gültiges E -Mail -Format - muss an RFC5322 entsprechen. |
| DL3059 | Info | Mehrere RUN Anweisungen. Konsolidierung betrachten. |
| DL3060 | Info | yarn cache clean fehlt nach yarn install . |
| DL3061 | Fehler | Ungültige Anweisungsreihenfolge. DockerFile muss mit FROM , ARG oder kommentieren. |
| DL4000 | Fehler | MAINTAINER ist veraltet. |
| DL4001 | Warnung | Verwenden Sie entweder WGet oder Curl, aber nicht beides. |
| DL4003 | Warnung | Mehrere CMD -Anweisungen gefunden. |
| DL4004 | Fehler | Mehrere ENTRYPOINT gefunden. |
| DL4005 | Warnung | Verwenden Sie SHELL , um die Standardschale zu ändern. |
| DL4006 | Warnung | Stellen Sie die SHELL Option -o Pipefail ein, bevor Sie mit einem Rohr darin RUN |
| SC1000 | $ wird nicht speziell verwendet und sollte daher entkommen werden. | |
| SC1001 | Dieses c wird in diesem Zusammenhang ein reguläres 'c' sein. | |
| SC1007 | Entfernen Sie den Speicherplatz nach = Wenn Sie versuchen, einen Wert zuzuweisen (oder für leere Zeichenfolge, verwenden Sie var='' ... ). | |
| SC1010 | Verwenden Sie Semikolon oder Linefeed vor done (oder zitieren Sie es, um es wörtlich zu machen). | |
| SC1018 | Dies ist ein unikodischer nicht bahnbrechender Raum. Löschen Sie es und geben Sie als Raum um. | |
| SC1035 | Sie brauchen hier einen Raum | |
| SC1045 | Es ist nicht foo &; bar , einfach foo & bar . | |
| SC1065 | Versuchen Sie, Parameter zu deklarieren? Nicht. Verwenden Sie () und beziehen Sie sich auf Parameter als $1 , $2 usw. usw. | |
| SC1066 | Verwenden Sie nicht $ auf der linken Seite der Aufgaben. | |
| SC1068 | Stellen Sie keine Leerzeichen um die = in Aufgaben. | |
| SC1077 | Für die Befehlsausdehnung sollte die Zecke nach links schrägen (`vs ´). | |
| SC1078 | Haben Sie vergessen, diese doppelt zitierte Zeichenfolge zu schließen? | |
| SC1079 | Dies ist eigentlich ein Endzitat, aber aufgrund des nächsten Chars sieht es verdächtig aus. | |
| SC1081 | Skripte sind fallsempfindlich. Verwenden Sie if , nicht If . | |
| SC1083 | Dieser {/} ist wörtlich. Überprüfen Sie den Ausdruck (fehlen ;/n ?) Oder zitieren Sie ihn. | |
| SC1086 | Verwenden Sie nicht $ für den Iteratornamen in Loops. | |
| SC1087 | Bei der Erweiterung von Arrays wie in ${array[idx]} sind Zahnspangen erforderlich. | |
| SC1095 | Sie benötigen einen Raum oder eine Linienfeed zwischen Funktionsname und Körper. | |
| SC1097 | Unerwartet == . Für die Zuordnung verwenden Sie = . Verwenden Sie zum Vergleich [ .. ] oder [[ .. ]] . | |
| SC1098 | Zitat-/Escape -Sonderzeichen bei Verwendung von eval , z. B. eval "a=(b)" . | |
| SC1099 | Sie benötigen einen Platz vor der # . | |
| SC2002 | Nutzlose Katze. Betrachten Sie cmd < file | .. oder cmd file | .. stattdessen. | |
| SC2015 | Beachten Sie, dass A && B || C ist nicht if-then-else. C kann laufen, wenn a wahr ist. | |
| SC2026 | Dieses Wort liegt außerhalb von Zitaten. Haben Sie beabsichtigt, "einzelne Zitate" "stattdessen" zu nisten? | |
| SC2028 | echo wächst die Fluchtsequenzen nicht aus. Betrachten Sie printf . | |
| SC2035 | Verwenden Sie ./*glob* oder -- *glob* , sodass Namen mit Strichen nicht zu Optionen werden. | |
| SC2039 | In POSIX SH ist etwas undefiniert. | |
| SC2046 | Zitieren Sie dies, um eine Wortaufteilung zu verhindern | |
| SC2086 | Doppelte Zitat, um Kugeln und Wortaufteilung zu verhindern. | |
| SC2140 | Das Wort ist in der Form "A"B"C" (b angegeben). Meinten Sie "ABC" oder "A"B"C" ? | |
| SC2154 | Var wird referenziert, aber nicht zugewiesen. | |
| SC2155 | Deklarieren und zuweisen separat, um Maskierungsrückgabewerte zu vermeiden. | |
| SC2164 | Verwenden Sie cd ... || exit , wenn cd fehlschlägt. |
Wenn Sie ein erfahrener Haskeller sind, wären wir sehr dankbar, wenn Sie unseren Code in einer Bewertung auseinander reißen würden.
Um zu kompilieren, benötigen Sie eine aktuelle Haskell-Umgebung und cabal-install .
Klon -Repository
git clone --recursive [email protected]:hadolint/hadolint.gitInstallieren Sie Abhängigkeiten und kompilieren Sie die Quelle
cabal configure
cabal build(Optional) Installieren Sie Hadolint auf Ihrem System
cabal installDer einfachste Weg, den Parser auszuprobieren, ist die Verwendung der Repl.
# start the repl
cabal repl
# overload strings to be able to use Text
:set -XOverloadedStrings
# import parser library
import Language.Docker
# parse instruction and look at AST representation
parseText " FROM debian:jessie "Kompilieren Sie mit Unit -Tests und führen Sie sie aus:
cabal configure --enable-tests
cabal build --enable-tests
cabal testIntegrationstests ausführen:
./integration_test.sh Die DockerFile -Syntax ist in der DockerFile -Referenz vollständig beschrieben. Schauen Sie sich einfach Syntax.hs im language-docker -Projekt an, um die AST-Definition anzuzeigen.
Hadolint verwendet viele Bibliotheken, um die schmutzige Arbeit zu erledigen. Insbesondere wird Sprachdocker verwendet, um DockerFiles zu analysieren und einen AST zu produzieren, der dann analysiert werden kann. Um Hadolint gegen eine benutzerdefinierte Version solcher Bibliotheken zu erstellen, machen Sie Folgendes. In diesem Beispiel wird Sprachdocker verwendet, aber es würde auch mit jeder anderen Bibliothek funktionieren.
/home/user/repos ) Klon Hadolint- und Sprachdocker-Git-Repositories cd /home/user/repos
git clone https://github.com/hadolint/hadolint.git
git clone https://github.com/hadolint/language-docker.gitNehmen Sie Ihre Änderungen an Sprachdocker vor
Bearbeiten Sie im Hadolint -Repo die Datei cabal.project , so dass die Eigenschaft packages auch auf das andere Repo verweist
[...]
packages :
.
../language-docker
[...] cd /home/user/repos/hadolint
cabal configure --enable-tests
cabal build --enable-tests
cabal test ReplicatedHQ/DockerFilelint, der andere vom Super-L. verwendete Verluste
Redcoolbeans/Dockerlint
Projectatomic/Dockerfile_lint
