hadolint
v2.12.0
Un linter dockerfile plus intelligent qui vous aide à créer des images Docker les meilleures pratiques. Le linter analyse le dockerfile dans un AST et effectue des règles en plus de l'AST. Il se tient sur les épaules de ShellCheck pour peindre le code bash dans les instructions RUN .
Consultez la version en ligne sur hadolint.github.io/hadolint 
Vous pouvez exécuter hadolint localement pour peindre votre dockerfile.
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 vient à la rescousse, offrant un moyen facile de gérer hadolint sur la plupart des plateformes. Il suffit de tuer votre Dockerfile à docker run :
docker run --rm -i hadolint/hadolint < Dockerfile
# OR
docker run --rm -i ghcr.io/hadolint/hadolint < Dockerfileou en utilisant Podman:
podman run --rm -i docker.io/hadolint/hadolint < Dockerfile
# OR
podman run --rm -i ghcr.io/hadolint/hadolint < Dockerfileou en utilisant Windows PowerShell:
cat .Dockerfile | docker run -- rm - i hadolint / hadolint Vous pouvez télécharger des binaires préconçus pour OSX, Windows et Linux à partir de la dernière page de version. Cependant, si cela ne fonctionne pas pour vous, veuillez retomber au conteneur (Docker), brew ou Source.
Sur OSX, vous pouvez utiliser Brew pour installer hadolint .
brew install hadolint Sur Windows, vous pouvez utiliser Scoop pour installer hadolint .
scoop install hadolint Sur les distributions qui ont l'installation nix , vous pouvez utiliser le package hadolint pour exécuter des coquilles ad hoc ou installer en permanence hadolint dans votre environnement.
Comme mentionné précédemment, hadolint est disponible en tant qu'image de conteneur:
docker pull hadolint/hadolint
# OR
docker pull ghcr.io/hadolint/hadolintSi vous avez besoin d'un conteneur avec un accès à la coquille, utilisez les variantes Debian ou Alpine:
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 Vous pouvez également construire hadolint localement. Vous avez besoin de Haskell et de l'outil Cabal Build pour construire le binaire.
git clone https://github.com/hadolint/hadolint
&& cd hadolint
&& cabal configure
&& cabal build
&& cabal installSi vous souhaitez que l'extension Hadolint Code VS utilise Hadolint dans un conteneur, vous pouvez utiliser le script de wrapper suivant:
#! /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)
Les fichiers de configuration peuvent être utilisés globalement ou par projet. Hadolint recherche des fichiers de configuration dans les emplacements suivants ou leurs équivalents spécifiques à la plate-forme dans cet ordre et utilise le premier exclusivement:
$PWD/.hadolint.yaml$XDG_CONFIG_HOME/hadolint.yaml$HOME/.config/hadolint.yaml$HOME/.hadolint/hadolint.yaml or $HOME/hadolint/config.yaml$HOME/.hadolint.yaml Dans Windows, la variable %LOCALAPPDATA% d'environnement est utilisée à la place de XDG_CONFIG_HOME . Les fichiers de configuration peuvent avoir des extensions yaml ou yml .
hadolint Schema de fichier de configuration YAML Full yaml
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 prend en charge la spécification des règles ignorées à l'aide d'un fichier de configuration. Le fichier de configuration doit être au format yaml . Il s'agit d'un fichier de configuration valide comme exemple:
ignored :
- DL3000
- SC1010 De plus, hadolint peut vous avertir lorsque des images de référentiels non fiables sont utilisés dans DockerFiles, vous pouvez ajouter les clés trustedRegistries du fichier de configuration, comme indiqué ci-dessous:
ignored :
- DL3000
- SC1010
trustedRegistries :
- docker.io
- my-company.com:5000
- " *.gcr.io "Si vous souhaitez remplacer la gravité des règles spécifiques, vous pouvez également le faire:
override :
error :
- DL3001
- DL3002
warning :
- DL3042
- DL3033
info :
- DL3032
style :
- DL3015 La sortie failure-threshold avec code d'échec uniquement lorsque les règles avec une gravité au-dessus du seuil sont violées (disponibles en v2.6.0 +)
failure-threshold : info
override :
warning :
- DL3042
- DL3033
info :
- DL3032 De plus, vous pouvez passer un fichier de configuration personnalisé dans la ligne de commande avec l'option --config
hadolint --config /path/to/config.yaml DockerfilePour passer un fichier de configuration personnalisé (à l'aide d'un chemin relatif ou absolu) dans un conteneur, utilisez la commande suivante:
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 < DockerfileEn plus des fichiers de configuration, Hadolint peut être configuré avec des variables d'environnement.
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 Lorsque vous utilisez des images de base avec des shells non-Posix par défaut (par exemple, les images basées sur Windows), un hadolint shell peut spécifier quelle coque utilise l'image de base, afin que Hadolint puisse ignorer automatiquement toutes les règles spécifiques au shell.
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# hadolint shell=powershell
RUN Get-Process notepad | Stop-Process Il est également possible d'ignorer les règles en ajoutant un commentaire spécial directement au-dessus de l'instruction Dockerfile pour laquelle vous souhaitez faire une exception. De tels commentaires ressemblent à # hadolint ignore=DL3001,SC1081 . Par exemple:
# hadolint ignore=DL3006
FROM ubuntu
# hadolint ignore=DL3003,SC1035
RUN cd /tmp && echo "hello!"Le commentaire "INLINE Ignores" s'applique uniquement à la déclaration qui le suit.
Les règles peuvent également être ignorées par fichier en utilisant le Global Ignore Pragma. Il fonctionne comme Inline Ignores, sauf qu'il s'applique à l'ensemble du fichier au lieu de la ligne suivante.
# hadolint global ignore=DL3003,DL3006,SC1035
FROM ubuntu
RUN cd /tmp && echo "foo" Hadolint est capable de vérifier si des étiquettes spécifiques sont présentes et sont conformes à un schéma d'étiquette prédéfini. Tout d'abord, un schéma d'étiquette doit être défini soit via la ligne de commande:
hadolint --require-label author:text --require-label version:semver Dockerfileou via le fichier de configuration:
label-schema :
author : text
contact : email
created : rfc3339
version : semver
documentation : url
git-revision : hash
license : spdx La valeur d'une étiquette peut être de text , url , semver , hash ou rfc3339 :
| Schéma | Description |
|---|---|
| texte | Rien |
| RFC3339 | Un temps, formaté selon RFC 3339 |
| Semver | Une version sémantique |
| URL | Un URI comme décrit dans RFC 3986 |
| hacher | Soit un hachage Git court ou long |
| spdx | Un identifiant de licence SPDX |
| Une adresse e-mail conforme à la RFC 5322 |
Par défaut, Hadolint ignore toute étiquette qui n'est pas spécifiée dans le schéma d'étiquette. Pour avertir contre ces étiquettes supplémentaires, activez les étiquettes strictes, en utilisant la ligne de commande:
hadolint --strict-labels --require-label version:semver Dockerfileou le fichier de configuration:
strict-labels : true Lorsque des étiquettes strictes sont activées, mais aucun schéma d'étiquette n'est spécifié, hadolint mettra en garde si une étiquette est présente.
Il s'agit d'un modèle commun pour remplir la valeur d'une étiquette non statiquement, mais plutôt dynamiquement au moment de la construction en utilisant une variable:
FROM debian:buster
ARG VERSION= "du-jour"
LABEL version= "${VERSION}" Pour permettre cela, le schéma d'étiquette doit spécifier text comme valeur pour cette étiquette:
label-schema :
version : text Pour obtenir la plupart de hadolint , il est utile de l'intégrer comme un chèque dans votre CI ou dans votre éditeur, ou comme un crochet de pré-commit, de pelucher votre Dockerfile pendant que vous l'écrivez. Voir nos documents d'intégration.
Une liste incomplète des règles implémentées. Cliquez sur le code d'erreur pour obtenir des informations plus détaillées.
Les règles avec le préfixe DL sont de hadolint . Jetez un œil aux Rules.hs pour trouver la mise en œuvre des règles.
Les règles avec le préfixe SC proviennent de ShellCheck (seules les règles les plus courantes sont répertoriées, il y en a des dizaines de plus).
Veuillez créer un problème si vous avez une idée pour une bonne règle.
| Règle | Gravité par défaut | Description |
|---|---|---|
| DL1001 | Ignorer | Veuillez vous abstenir d'utiliser Inline Ignore Pragmas # hadolint ignore=DLxxxx . |
| DL3000 | Erreur | Utilisez Absolute Workdir. |
| DL3001 | Informations | Pour certaines commandes de bash, cela n'a aucun sens de les exécuter dans un conteneur Docker comme SSH, VIM, Shutdown, Service, PS, gratuit, Top, Kill, Mount, ifconfig. |
| DL3002 | Avertissement | Le dernier utilisateur ne doit pas être root. |
| DL3003 | Avertissement | Utilisez WorkDIR pour passer à un répertoire. |
| DL3004 | Erreur | N'utilisez pas Sudo car cela conduit à un comportement imprévisible. Utilisez un outil comme GOSU pour appliquer la racine. |
| DL3006 | Avertissement | Taguez toujours explicitement la version d'une image. |
| DL3007 | Avertissement | L'utilisation des derniers est sujette aux erreurs si l'image se mettra à jour. Épinglez la version explicitement à une balise de version. |
| DL3008 | Avertissement | Versions PIN dans apt-get install . |
| DL3009 | Informations | Supprimez les listes APT-Get après avoir installé quelque chose. |
| DL3010 | Informations | Utilisez Ajouter pour extraire des archives dans une image. |
| DL3011 | Erreur | Les ports Unix valides varient de 0 à 65535. |
| DL3012 | Erreur | Plusieurs instructions HEALTHCHECK . |
| DL3013 | Avertissement | Versions PIN dans PIP. |
| DL3014 | Avertissement | Utilisez le commutateur -y . |
| DL3015 | Informations | Évitez les packages supplémentaires en spécifiant --no-install-recommends . |
| DL3016 | Avertissement | Versions PIN dans npm . |
| DL3018 | Avertissement | Versions PIN dans apk add . Au lieu d' apk add <package> Utilisez apk add <package>=<version> . |
| DL3019 | Informations | Utilisez le commutateur --no-cache pour éviter la nécessité d'utiliser --update et supprimer /var/cache/apk/* lors de l'installation de packages. |
| DL3020 | Erreur | Utilisez COPY au lieu ADD pour les fichiers et les dossiers. |
| DL3021 | Erreur | COPY avec plus de 2 arguments nécessite que le dernier argument se termine avec / |
| DL3022 | Avertissement | COPY --from devrait faire référence à un FROM précédemment défini |
| DL3023 | Erreur | COPY --from ne peut pas référencer le sien FROM l'alias |
| DL3024 | Erreur | FROM alias (noms de scène) doivent être uniques |
| DL3025 | Avertissement | Utiliser les arguments JSON Notation pour les arguments CMD et Pointpoint |
| DL3026 | Erreur | Utilisez uniquement un registre autorisé dans l' FROM image |
| DL3027 | Avertissement | N'utilisez pas apt car il est censé être un outil de l'utilisateur final, utilisez à la place apt-get ou apt-cache à la place |
| DL3028 | Avertissement | Versions PIN dans l'installation de gemmes. Au lieu de gem install <gem> Utilisez gem install <gem>:<version> |
| DL3029 | Avertissement | N'utilisez pas le drapeau - plateform avec. |
| DL3030 | Avertissement | Utilisez le commutateur -y pour éviter yum install -y <package> |
| DL3032 | Avertissement | yum clean all Missing après la commande YUM. |
| DL3033 | Avertissement | Spécifiez la version avec yum install -y <package>-<version> |
| DL3034 | Avertissement | Commutateur non interactif manquant à partir de la commande zypper : zypper install -y |
| DL3035 | Avertissement | N'utilisez pas zypper dist-upgrade . |
| DL3036 | Avertissement | zypper clean manquant après l'utilisation de Zypper. |
| DL3037 | Avertissement | Spécifiez la version avec zypper install -y <package>[=]<version> . |
| DL3038 | Avertissement | Utilisez le commutateur -y pour éviter dnf install -y <package> |
| DL3040 | Avertissement | dnf clean all Missing après la commande DNF. |
| DL3041 | Avertissement | Spécifiez la version avec dnf install -y <package>-<version> |
| DL3042 | Avertissement | Évitez le répertoire de cache avec pip install --no-cache-dir <package> . |
| DL3043 | Erreur | ONBUILD , FROM ou MAINTAINER déclenché de l'intérieur de l'instruction ONBUILD . |
| DL3044 | Erreur | Ne vous référez pas à une variable d'environnement dans la même instruction ENV lorsqu'elle est définie. |
| DL3045 | Avertissement | COPY sur une destination relative sans jeu WORKDIR . |
| DL3046 | Avertissement | useradd sans drapeau -l et UID élevé entraîneront une image excessivement grande. |
| DL3047 | Informations | wget WANTS FLAG --progress entraînera des journaux de construction excessivement gonflés lors du téléchargement de fichiers plus grands. |
| DL3048 | Style | Clé d'étiquette non valide |
| DL3049 | Informations | Label <label> est manquant. |
| DL3050 | Informations | Étiquettes superflues présentes. |
| DL3051 | Avertissement | Label <label> est vide. |
| DL3052 | Avertissement | Label <label> n'est pas une URL valide. |
| DL3053 | Avertissement | Label <label> n'est pas un format de temps valide - doit être conforme à RFC3339. |
| DL3054 | Avertissement | Label <label> n'est pas un identifiant de licence SPDX valide. |
| DL3055 | Avertissement | Label <label> n'est pas un hachage GIT valide. |
| DL3056 | Avertissement | Label <label> ne se conforme pas au versioning sémantique. |
| DL3057 | Ignorer | Instruction HEALTHCHECK manquante. |
| DL3058 | Avertissement | Label <label> n'est pas un format de messagerie valide - doit être conforme à RFC5322. |
| DL3059 | Informations | Plusieurs instructions RUN consécutives. Considérez la consolidation. |
| DL3060 | Informations | yarn cache clean une manquante après l'exécution yarn install . |
| DL3061 | Erreur | Ordonnance d'instructions non valide. Dockerfile doit commencer par FROM ARG ou commentaire. |
| DL4000 | Erreur | MAINTAINER est obsolète. |
| DL4001 | Avertissement | Utilisez Wget ou Curl mais pas les deux. |
| DL4003 | Avertissement | Plusieurs instructions CMD trouvées. |
| DL4004 | Erreur | Instructions multiples ENTRYPOINT trouvées. |
| DL4005 | Avertissement | Utilisez SHELL pour modifier le shell par défaut. |
| DL4006 | Avertissement | Définissez l'option SHELL -O Pipefail avant RUN avec un tuyau dedans |
| SC1000 | $ n'est pas utilisé spécialement et devrait donc être échappé. | |
| SC1001 | Ce sera un c 'c' régulier dans ce contexte. | |
| SC1007 | Supprimez l'espace après = si vous essayez d'attribuer une valeur (ou pour une chaîne vide, utilisez var='' ... ). | |
| SC1010 | Utilisez un demi-colon ou une alimentation avant done (ou cite pour le rendre littéral). | |
| SC1018 | Il s'agit d'un espace non révolutionnaire Unicode. Supprimez-le et retapez comme espace. | |
| SC1035 | Vous avez besoin d'un espace ici | |
| SC1045 | Ce n'est pas foo &; bar , juste foo & bar . | |
| SC1065 | Vous essayez de déclarer des paramètres? Ne le faites pas. Use () et se référer aux paramètres de $1 , $2 etc. | |
| SC1066 | N'utilisez pas $ sur le côté gauche des affectations. | |
| SC1068 | Ne mettez pas des espaces autour des missions = . | |
| SC1077 | Pour l'expansion des commandes, la coche devrait s'incliner (`vs ´). | |
| SC1078 | Avez-vous oublié de fermer cette chaîne à double cible? | |
| SC1079 | Il s'agit en fait d'un devis final, mais en raison du prochain char, il semble suspect. | |
| SC1081 | Les scripts sont sensibles à la casse. Utiliser if , pas If . | |
| SC1083 | Ce {/} est littéral. Vérifiez l'expression (manquant ;/n ?) Ou citez-le. | |
| SC1086 | N'utilisez pas $ sur le nom de l'itérateur pour les boucles. | |
| SC1087 | Les accolades sont nécessaires lors de l'expansion des tableaux, comme dans ${array[idx]} . | |
| SC1095 | Vous avez besoin d'un espace ou d'un flux de ligne entre le nom et le corps de la fonction. | |
| SC1097 | Inattendu == . Pour l'attribution, utilisez = . À titre de comparaison, utilisez [ .. ] ou [[ .. ]] . | |
| SC1098 | Quote / Échappement des caractères spéciaux Lorsque vous utilisez eval , par exemple eval "a=(b)" . | |
| SC1099 | Vous avez besoin d'un espace avant le # . | |
| SC2002 | Chat inutile. Considérez cmd < file | .. ou cmd file | .. plutôt. | |
| SC2015 | Notez que A && B || C n'est pas si-then-else. C peut fonctionner lorsque A est vrai. | |
| SC2026 | Ce mot est en dehors des citations. Avez-vous eu l'intention de «nid» «« citations simples »« «à la place»? | |
| SC2028 | echo n'élargira pas les séquences d'évacuation. Considérez printf . | |
| SC2035 | Utilisez ./*glob* ou -- *glob* Les noms avec des tirets ne deviendront donc pas des options. | |
| SC2039 | Dans Posix Sh, quelque chose n'est pas défini. | |
| SC2046 | Citez ceci pour éviter la division des mots | |
| SC2086 | Double devis pour empêcher le globbing et la division des mots. | |
| SC2140 | Le mot est sous la forme "A"B"C" (b indiqué). Vouliez-vous dire "ABC" ou "A"B"C" ? | |
| SC2154 | var est référencé mais non attribué. | |
| SC2155 | Déclarez et affectez séparément pour éviter le masquage des valeurs de retour. | |
| SC2164 | Utilisez cd ... || exit dans le cas où cd échoue. |
Si vous êtes un Haskeller expérimenté, nous serions très reconnaissants si vous déchiriez notre code dans une revue.
Pour compiler, vous aurez besoin d'un environnement Haskell récent et cabal-install .
Référentiel de clones
git clone --recursive [email protected]:hadolint/hadolint.gitInstallez les dépendances et compilez la source
cabal configure
cabal build(Facultatif) Installez Hadolint sur votre système
cabal installLa façon la plus simple d'essayer l'analyseur est d'utiliser le REP.
# 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 "Compilez avec des tests unitaires et exécutez-les:
cabal configure --enable-tests
cabal build --enable-tests
cabal testExécutez des tests d'intégration:
./integration_test.sh La syntaxe Dockerfile est entièrement décrite dans la référence Dockerfile. Jetez un œil à Syntax.hs dans le projet language-docker pour voir la définition AST.
Hadolint utilise de nombreuses bibliothèques pour faire le sale boulot. En particulier, le langage-docker est utilisé pour analyser Dockerfiles et produire un AST qui peut ensuite être analysé. Pour construire Hadolint contre une version personnalisée de ces bibliothèques, faites ce qui suit. Cet exemple utilise le langage-Docker, mais il fonctionnerait également avec n'importe quelle autre bibliothèque.
/home/user/repos ) clone hadolint et docker git docker git repositories cd /home/user/repos
git clone https://github.com/hadolint/hadolint.git
git clone https://github.com/hadolint/language-docker.gitApportez vos modifications à la langue-docker
Dans le dépôt de Hadolint, modifiez le fichier cabal.project , de sorte que la propriété packages pointe également de l'autre repo
[...]
packages :
.
../language-docker
[...] cd /home/user/repos/hadolint
cabal configure --enable-tests
cabal build --enable-tests
cabal test reproduithq / dockerfilelint, l'autre linter utilisé par le super-clou
RedCoolBeans / Dockerlint
projectatomic / dockerfile_lint
