Use this command to install Haskell Dockerfile Linter:
winget install --id=hadolint.hadolint -e
A smarter Dockerfile linter that helps you build best practice Docker images. The linter parses the Dockerfile into an AST and performs rules on top of the AST. It stands on the shoulders of ShellCheck to lint the Bash code inside RUN instructions.
Hadolint is a Dockerfile linter designed to help you build best-practice Docker images by identifying potential issues and enforcing consistency. It analyzes Dockerfiles by parsing them into an Abstract Syntax Tree (AST) and applying rules to ensure compliance with Docker best practices. Additionally, it leverages ShellCheck to lint the Bash code within RUN instructions, ensuring that the inline scripts are also secure and maintainable.
Key Features:
AST-Based Analysis: Hadolint parses Dockerfiles into an AST, enabling precise rule-based analysis for better accuracy.
Bash Code Linting: Integrates with ShellCheck to validate Bash scripts inside RUN instructions, addressing common shell scripting pitfalls.
Allows developers to ignore specific rules inline using comments, providing flexibility without compromising maintainability.
README
Haskell Dockerfile Linter
A smarter Dockerfile linter that helps you build best practice Docker
images. The linter parses the Dockerfile into an AST and performs rules on
top of the AST. It stands on the shoulders of ShellCheck to lint
the Bash code inside RUN instructions.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git SCM to Windows while providing appropriate user interfaces for experienced Git users and novices alike.
GitHub CLI (gh) is a command-line tool that brings pull requests, issues, GitHub Actions, and other GitHub features to your terminal, so you can do all your work in one place.
The Azure command-line interface (Azure CLI) is a set of commands used to create and manage Azure resources. The Azure CLI is available across Azure services and is designed to get you working quickly with Azure, with an emphasis on automation.
The AWS CLI is an open source tool built on top of the AWS SDK for Python (Boto) that provides commands for interacting with AWS services.
With minimal configuration, you can start using all of the functionality provided by the AWS Management Console from your favorite terminal program.
zoxide is a smarter cd command, inspired by z and autojump. It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes. zoxide works on all major shells.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git for Windows focuses on offering a lightweight, native set of tools that bring the full feature set of the Git SCM to Windows while providing appropriate user interfaces for experienced Git users and novices alike.
GitHub CLI (gh) is a command-line tool that brings pull requests, issues, GitHub Actions, and other GitHub features to your terminal, so you can do all your work in one place.
The Azure command-line interface (Azure CLI) is a set of commands used to create and manage Azure resources. The Azure CLI is available across Azure services and is designed to get you working quickly with Azure, with an emphasis on automation.
The AWS CLI is an open source tool built on top of the AWS SDK for Python (Boto) that provides commands for interacting with AWS services.
With minimal configuration, you can start using all of the functionality provided by the AWS Management Console from your favorite terminal program.
zoxide is a smarter cd command, inspired by z and autojump. It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes. zoxide works on all major shells.
Configurable Rulesets: Supports custom configurations for ignored rules and trusted registries, enabling tailored linting workflows.
Multi-Platform Compatibility: Available as prebuilt binaries for macOS, Linux, and Windows, ensuring widespread accessibility.
Containerized Execution: Provides Docker and Podman images, allowing seamless integration into CI/CD pipelines without local installations.
Audience & Benefit:
Ideal for DevOps engineers, developers, and teams focused on building secure, maintainable, and efficient containerized applications. By identifying potential issues early in the development cycle, Hadolint helps reduce technical debt, improves code quality, and ensures compliance with Docker best practices, ultimately leading to more robust and production-ready Docker images.
Hadolint can be installed via winget or used directly from its Docker image, making it easy to integrate into your workflow.
You can run hadolint locally to lint your Dockerfile.
hadolint
hadolint --ignore DL3003 --ignore DL3006 # exclude specific rules
hadolint --trusted-registry my-company.com:500 # Warn when using untrusted FROM images
Docker comes to the rescue, providing an easy way how to run hadolint on most
platforms.
Just pipe your Dockerfile to docker run:
docker run --rm -i hadolint/hadolint < Dockerfile
# OR
docker run --rm -i ghcr.io/hadolint/hadolint < Dockerfile
podman run --rm -i docker.io/hadolint/hadolint < Dockerfile
# OR
podman run --rm -i ghcr.io/hadolint/hadolint < Dockerfile
or using Windows PowerShell:
cat .\Dockerfile | docker run --rm -i hadolint/hadolint
Install
You can download prebuilt binaries for OSX, Windows and Linux from the latest
release page. However, if this does not work for you, please fall back to
container (Docker), brew or source installation.
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)
Configure
Configuration files can be used globally or per project.
Hadolint looks for configuration files in the following locations or their
platform specific equivalents in this order and uses the first one exclusively:
$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, the %LOCALAPPDATA% environment variable is used instead of
XDG_CONFIG_HOME. Config files can have either yaml or yml extensions.
hadolint full yaml config file schema
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 supports specifying the ignored rules using a configuration
file. The configuration file should be in yaml format. This is one
valid configuration file as an example:
ignored:
- DL3000
- SC1010
Additionally, hadolint can warn you when images from untrusted
repositories are being used in Dockerfiles, you can append the
trustedRegistries keys to the configuration file, as shown below:
Additionally, you can pass a custom configuration file in the command line with
the --config option
hadolint --config /path/to/config.yaml Dockerfile
To pass a custom configuration file (using relative or absolute path) to
a container, use the following command:
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 < Dockerfile
In addition to config files, Hadolint can be configured with environment
variables.
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
Non-Posix Shells
When using base images with non-posix shells as default (e.g. Windows based
images) a special pragma hadolint shell can specify which shell the base image
uses, so that Hadolint can automatically ignore all shell-specific rules.
FROM mcr.microsoft.com/windows/servercore:ltsc2022
# hadolint shell=powershell
RUN Get-Process notepad | Stop-Process
Ignoring Rules
Inline ignores
It is also possible to ignore rules by adding a special comment directly
above the Dockerfile statement for which you want to make an exception for.
Such comments look like
# hadolint ignore=DL3001,SC1081. For example:
# hadolint ignore=DL3006
FROM ubuntu
# hadolint ignore=DL3003,SC1035
RUN cd /tmp && echo "hello!"
The comment "inline ignores" applies only to the statement following it.
Global ignores
Rules can also be ignored on a per-file basis using the global ignore pragma.
It works just like inline ignores, except that it applies to the whole file
instead of just the next line.
# hadolint global ignore=DL3003,DL3006,SC1035
FROM ubuntu
RUN cd /tmp && echo "foo"
Linting Labels
Hadolint is able to check if specific labels are present and conform
to a predefined label schema.
First, a label schema must be defined either via the command line:
By default, Hadolint ignores any label that is not specified in the label schema. To
warn against such additional labels, turn on strict labels, using the command line:
When strict labels is enabled, but no label schema is specified, hadolint
will warn if any label is present.
Note on dealing with variables in labels
It is a common pattern to fill the value of a label not statically, but rather
dynamically at build time by using a variable:
FROM debian:buster
ARG VERSION="du-jour"
LABEL version="${VERSION}"
To allow this, the label schema must specify text as value for that label:
label-schema:
version: text
Integrations
To get most of hadolint, it is useful to integrate it as a check in your CI
or into your editor, or as a pre-commit hook, to lint your Dockerfile as you
write it. See our Integration docs.
Not following: Reasons include: file not found, no permissions, not included on the command line, not allowing shellcheck to follow files with -x, etc.
The easiest way to try out the parser is using the 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"
Tests
Compile with unit tests and run them:
cabal configure --enable-tests
cabal build --enable-tests
cabal test
Run integration tests:
./integration_test.sh
AST
Dockerfile syntax is fully described in the Dockerfile reference.
Just take a look at Syntax.hs in the language-docker project to see
the AST definition.
Building against custom libraries
Hadolint uses many libraries to do the dirty work. In particular,
language-docker is used to parse Dockerfiles and produce an AST which then can
be analyzed. To build Hadolint against a custom version of such libraries, do
the following. This example uses language-docker, but it would work with any
other library as well.
In the same directory (e.g. /home/user/repos) clone Hadolint and
language-docker git repositories
cd /home/user/repos
git clone https://github.com/hadolint/hadolint.git
git clone https://github.com/hadolint/language-docker.git
Make your modifications to language-docker
In the Hadolint repo, edit the cabal.project file, such that the
packages property points to the other repo too
[...]
packages:
.
../language-docker
[...]
Recompile Hadolint and run the tests
cd /home/user/repos/hadolint
cabal configure --enable-tests
cabal build --enable-tests
cabal test
Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images.
Podman provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine.
Most users can simply alias Docker to Podman (alias docker=podman) without any problems.
Similar to other common Container Engines (Docker, CRI-O, containerd), Podman relies on an OCI compliant Container Runtime (runc, crun, runv, etc) to interface with the operating system and create the running containers.
This makes the running containers created by Podman nearly indistinguishable from those created by any other common container engine.
Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images.
Podman provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine.
Most users can simply alias Docker to Podman (alias docker=podman) without any problems.
Similar to other common Container Engines (Docker, CRI-O, containerd), Podman relies on an OCI compliant Container Runtime (runc, crun, runv, etc) to interface with the operating system and create the running containers.
This makes the running containers created by Podman nearly indistinguishable from those created by any other common container engine.
AI Shell is a CLI tool that brings the power of artificial intelligence directly to your command line! Designed to help you get command assistance from various AI assistants, AI Shell is a versatile tool to help you become more productive in the command line. We call these various AI assistant providers agents. You can use agents to interact with different generative AI models or other AI/ML/assistant providers in a conversational manner.
AI Shell is a CLI tool that brings the power of artificial intelligence directly to your command line! Designed to help you get command assistance from various AI assistants, AI Shell is a versatile tool to help you become more productive in the command line. We call these various AI assistant providers agents. You can use agents to interact with different generative AI models or other AI/ML/assistant providers in a conversational manner.
AI Shell is a CLI tool that brings the power of artificial intelligence directly to your command line! Designed to help you get command assistance from various AI assistants, AI Shell is a versatile tool to help you become more productive in the command line. We call these various AI assistant providers agents. You can use agents to interact with different generative AI models or other AI/ML/assistant providers in a conversational manner.
A vulnerability scanner for container images and filesystems. Easily install the binary to try it out.
Works with Syft, the powerful SBOM (software bill of materials) tool for container images and filesystems.
A vulnerability scanner for container images and filesystems. Easily install the binary to try it out.
Works with Syft, the powerful SBOM (software bill of materials) tool for container images and filesystems.
A vulnerability scanner for container images and filesystems. Easily install the binary to try it out.
Works with Syft, the powerful SBOM (software bill of materials) tool for container images and filesystems.
