hadolint/hadolint-action

GitHub action for Hadolint, A Dockerfile linting tool

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.

🌐 Check the online version on hadolint.github.io/hadolint

Table of Contents

• How to use
• Install
• CLI
• Configure
• Non-Posix Shells
• Ignoring Rules
  • Inline ignores
  • Global ignores
• Linting Labels
  • Note on dealing with variables in labels
• Integrations
• Rules
• Develop
  • Setup
  • REPL
  • Tests
  • AST
  • Building against custom libraries
• Alternatives

How to use

You can run hadolint locally to lint your 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 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

or using Podman:

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.

On OSX, you can use brew to install hadolint.

brew install hadolint

On Windows, you can use scoop to install hadolint.

scoop install hadolint

On distributions that have nix installed, you can use the hadolint package to run ad-hoc shells or permanently install hadolint into your environment.

As mentioned earlier, hadolint is available as a container image:

docker pull hadolint/hadolint
# OR
docker pull ghcr.io/hadolint/hadolint

If you need a container with shell access, use the Debian or Alpine variants:

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

You can also build hadolint locally. You need Haskell and the cabal build tool to build the binary.

git clone https://github.com/hadolint/hadolint \
  && cd hadolint \
  && cabal configure \
  && cabal build \
  && cabal install

If you want the VS Code Hadolint extension to use Hadolint in a container, you can use the following wrapper script:

#!/bin/bash
dockerfile="$1"
shift
docker run --rm -i hadolint/hadolint hadolint "$@" - < "$dockerfile"

CLI

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)

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:

ignored:
  - DL3000
  - SC1010

trustedRegistries:
  - docker.io
  - my-company.com:5000
  - "*.gcr.io"

If you want to override the severity of specific rules, you can do that too:

override:
  error:
    - DL3001
    - DL3002
  warning:
    - DL3042
    - DL3033
  info:
    - DL3032
  style:
    - DL3015

failure-threshold Exit with failure code only when rules with a severity above THRESHOLD are violated (Available in v2.6.0+)

failure-threshold: info
override:
  warning:
    - DL3042
    - DL3033
  info:
    - DL3032

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:

hadolint --require-label author:text --require-label version:semver Dockerfile

or via the config file:

label-schema:
  author: text
  contact: email
  created: rfc3339
  version: semver
  documentation: url
  git-revision: hash
  license: spdx

The value of a label can be either of text, url, semver, hash or rfc3339:

Schema	Description
text	Anything
rfc3339	A time, formatted according to RFC 3339
semver	A semantic version
url	A URI as described in RFC 3986
hash	Either a short or a long Git hash
spdx	An SPDX license identifier
email	An email address conforming to RFC 5322

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:

hadolint --strict-labels --require-label version:semver Dockerfile

or the config file:

strict-labels: true

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.

• Code Review Platform Integrations
• Continuous Integrations
• Editor Integrations
• Version Control Integrations

Rules

An incomplete list of implemented rules. Click on the error code to get more detailed information.

• Rules with the prefix DL are from hadolint. Have a look at Rules.hs to find the implementation of the rules.

• Rules with the SC prefix are from ShellCheck (only the most common rules are listed, there are dozens more).

Please create an issue if you have an idea for a good rule.

Rule	Default Severity	Description
DL1001	Ignore	Please refrain from using inline ignore pragmas # hadolint ignore=DLxxxx.
DL3000	Error	Use absolute WORKDIR.
DL3001	Info	For some bash commands it makes no sense running them in a Docker container like ssh, vim, shutdown, service, ps, free, top, kill, mount, ifconfig.
DL3002	Warning	Last user should not be root.
DL3003	Warning	Use WORKDIR to switch to a directory.
DL3004	Error	Do not use sudo as it leads to unpredictable behavior. Use a tool like gosu to enforce root.
DL3006	Warning	Always tag the version of an image explicitly.
DL3007	Warning	Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag.
DL3008	Warning	Pin versions in apt-get install.
DL3009	Info	Delete the apt-get lists after installing something.
DL3010	Info	Use ADD for extracting archives into an image.
DL3011	Error	Valid UNIX ports range from 0 to 65535.
DL3012	Error	Multiple HEALTHCHECK instructions.
DL3013	Warning	Pin versions in pip.
DL3014	Warning	Use the -y switch.
DL3015	Info	Avoid additional packages by specifying --no-install-recommends.
DL3016	Warning	Pin versions in npm.
DL3018	Warning	Pin versions in apk add. Instead of apk add <package> use apk add <package>=<version>.
DL3019	Info	Use the --no-cache switch to avoid the need to use --update and remove /var/cache/apk/* when done installing packages.
DL3020	Error	Use COPY instead of ADD for files and folders.
DL3021	Error	COPY with more than 2 arguments requires the last argument to end with /
DL3022	Warning	COPY --from should reference a previously defined FROM alias
DL3023	Error	COPY --from cannot reference its own FROM alias
DL3024	Error	FROM aliases (stage names) must be unique
DL3025	Warning	Use arguments JSON notation for CMD and ENTRYPOINT arguments
DL3026	Error	Use only an allowed registry in the FROM image
DL3027	Warning	Do not use apt as it is meant to be an end-user tool, use apt-get or apt-cache instead
DL3028	Warning	Pin versions in gem install. Instead of gem install <gem> use gem install <gem>:<version>
DL3029	Warning	Do not use --platform flag with FROM.
DL3030	Warning	Use the -y switch to avoid manual input yum install -y <package>
DL3032	Warning	yum clean all missing after yum command.
DL3033	Warning	Specify version with yum install -y <package>-<version>
DL3034	Warning	Non-interactive switch missing from zypper command: zypper install -y
DL3035	Warning	Do not use zypper dist-upgrade.
DL3036	Warning	zypper clean missing after zypper use.
DL3037	Warning	Specify version with zypper install -y <package>[=]<version>.
DL3038	Warning	Use the -y switch to avoid manual input dnf install -y <package>
DL3040	Warning	dnf clean all missing after dnf command.
DL3041	Warning	Specify version with dnf install -y <package>-<version>
DL3042	Warning	Avoid cache directory with pip install --no-cache-dir <package>.
DL3043	Error	ONBUILD, FROM or MAINTAINER triggered from within ONBUILD instruction.
DL3044	Error	Do not refer to an environment variable within the same ENV statement where it is defined.
DL3045	Warning	COPY to a relative destination without WORKDIR set.
DL3046	Warning	useradd without flag -l and high UID will result in excessively large Image.
DL3047	Info	wget without flag --progress will result in excessively bloated build logs when downloading larger files.
DL3048	Style	Invalid Label Key
DL3049	Info	Label <label> is missing.
DL3050	Info	Superfluous label(s) present.
DL3051	Warning	Label <label> is empty.
DL3052	Warning	Label <label> is not a valid URL.
DL3053	Warning	Label <label> is not a valid time format - must conform to RFC3339.
DL3054	Warning	Label <label> is not a valid SPDX license identifier.
DL3055	Warning	Label <label> is not a valid git hash.
DL3056	Warning	Label <label> does not conform to semantic versioning.
DL3057	Ignore	HEALTHCHECK instruction missing.
DL3058	Warning	Label <label> is not a valid email format - must conform to RFC5322.
DL3059	Info	Multiple consecutive RUN instructions. Consider consolidation.
DL3060	Info	yarn cache clean missing after yarn install was run.
DL3061	Error	Invalid instruction order. Dockerfile must begin with FROM, ARG or comment.
DL4000	Error	MAINTAINER is deprecated.
DL4001	Warning	Either use Wget or Curl but not both.
DL4003	Warning	Multiple CMD instructions found.
DL4004	Error	Multiple ENTRYPOINT instructions found.
DL4005	Warning	Use SHELL to change the default shell.
DL4006	Warning	Set the SHELL option -o pipefail before RUN with a pipe in it
SC1000		$ is not used specially and should therefore be escaped.
SC1001		This \c will be a regular 'c' in this context.
SC1007		Remove space after = if trying to assign a value (or for empty string, use var='' ...).
SC1010		Use semicolon or linefeed before done (or quote to make it literal).
SC1018		This is a unicode non-breaking space. Delete it and retype as space.
SC1035		You need a space here
SC1045		It's not foo &; bar, just foo & bar.
SC1065		Trying to declare parameters? Don't. Use () and refer to params as $1, $2 etc.
SC1066		Don't use $ on the left side of assignments.
SC1068		Don't put spaces around the = in assignments.
SC1077		For command expansion, the tick should slant left (` vs ´).
SC1078		Did you forget to close this double-quoted string?
SC1079		This is actually an end quote, but due to next char, it looks suspect.
SC1081		Scripts are case sensitive. Use if, not If.
SC1083		This {/} is literal. Check expression (missing ;/\n?) or quote it.
SC1086		Don't use $ on the iterator name in for loops.
SC1087		Braces are required when expanding arrays, as in ${array[idx]}.
SC1095		You need a space or linefeed between the function name and body.
SC1097		Unexpected ==. For assignment, use =. For comparison, use [ .. ] or [[ .. ]].
SC1098		Quote/escape special characters when using eval, e.g. eval "a=(b)".
SC1099		You need a space before the #.
SC2002		Useless cat. Consider cmd < file | .. or cmd file | .. instead.
SC2015		Note that A && B || C is not if-then-else. C may run when A is true.
SC2026		This word is outside of quotes. Did you intend to 'nest '"'single quotes'"' instead'?
SC2028		echo won't expand escape sequences. Consider printf.
SC2035		Use ./*glob* or -- *glob* so names with dashes won't become options.
SC2039		In POSIX sh, something is undefined.
SC2046		Quote this to prevent word splitting
SC2086		Double quote to prevent globbing and word splitting.
SC2140		Word is in the form "A"B"C" (B indicated). Did you mean "ABC" or "A\"B\"C"?
SC2154		var is referenced but not assigned.
SC2155		Declare and assign separately to avoid masking return values.
SC2164		Use cd ... || exit in case cd fails.

Develop

If you are an experienced Haskeller, we would be very grateful if you would tear our code apart in a review.

To compile, you will need a recent Haskell environment and cabal-install.

Setup

1. Clone repository

   git clone --recursive [email protected]:hadolint/hadolint.git

2. Install dependencies and compile source

   cabal configure
   cabal build

3. (Optional) Install Hadolint on your system

   cabal install

REPL

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.

1. 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

2. Make your modifications to language-docker

3. In the Hadolint repo, edit the cabal.project file, such that the packages property points to the other repo too

[...]
packages:
  .
  ../language-docker
[...]

4. Recompile Hadolint and run the tests

cd /home/user/repos/hadolint
cabal configure --enable-tests
cabal build --enable-tests
cabal test

Alternatives

• replicatedhq/dockerfilelint, the other linter used by the super-linter

• RedCoolBeans/dockerlint

• projectatomic/dockerfile_lint

hadolint-action's Issues

How to lint multiple dockerfiles, without specifying the action for each?

With the version on the terminal, I can run it like so and get multiple files linted:

+ $ hadolint Dockerfile*
Dockerfile-test1:9 DL3003 warning: Use WORKDIR to switch to a directory
Dockerfile-test2:21 DL3003 warning: Use WORKDIR to switch to a directory

But with the action, I can't get it working:

      - uses: hadolint/[email protected]
        with:
          dockerfile: Dockerfile*

produces

hadolint: Dockerfile*: openBinaryFile: does not exist (No such file or directory)

It acts like I would use single quotes in bash to prevent wildcard expansion:

+ $ hadolint 'Dockerfile*'
hadolint: Dockerfile*: openBinaryFile: does not exist (No such file or directory)

Enable dependabot in Settings

You should be able to enable dependabot via Settings -> Code security and analysis on the repo. You'll then need to enable Dependabot alerts, and Dependabot security updates. This should then start creating merge requests when hadolint gets updated, as well as when github actions themselves get updated.

Improvements: no-fail flag and file output

Hi

There are two options that i think are missed in the action and would be quite helpful. The first one is the no-fail flag. The second one would be to output the result of the scan to a file

Do you think those two additions are useful? If so, i can do a PR with those changes

Thanks

Capture severity in problem matcher

problem-matcher.json doesn't capture severity so all findings are treated as errors.

Please capture severity and set it.
https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md

Reported issues wont fail the build

Is there a way to fail the build on reported issues?

The build is reported green, even though there's eg. an error.

      - uses: hadolint/[email protected]
        with:
          dockerfile: << Path to Dockerfile here >>
          no-fail: false # Same without this line

I have tried setting no-fail to false, but there's no difference to without the setting.

How recursive scan from a defined directory?

Error: No hadolint failure but Actions job fails

No hadolint failure but Actions job fails when executing below actions.

Execution log

Actions yaml (part of hadolint job)

  lint-dockerfile:
    runs-on: ubuntu-20.04
    timeout-minutes: 5

    steps:
      - uses: actions/checkout@v3

      - name: hadolint (dockerfile linter)
        uses: hadolint/hadolint-action@f988afea3da57ee48710a9795b6bb677cc901183
        with:
          recursive: true

---

Workaround: Actions success when setting failure-threshold: "warning" option.
But even if hadolint fails with info severity, Actions job will succeed😢.

  lint-dockerfile:
    runs-on: ubuntu-20.04
    timeout-minutes: 5

    steps:
      - uses: actions/checkout@v3

      - name: hadolint (dockerfile linter)
        uses: hadolint/hadolint-action@f988afea3da57ee48710a9795b6bb677cc901183
        with:
          recursive: true
          failure-threshold: "warning"

Do you support config file as input?

Hadolint --config option?

How to use hadolint action within organization repo?

Consider moving to hadolint org

This action is great, but would be excellent for confidence in the security of the code if it was under the hadolint org.

@lorenzo is this something you could help facilitate?

Generate report (and maybe SARIF format)

Hi

Is there any feature to return the results in a report file? Ideally it might be a sarif file.

If not, it would be a nice addition and i might be able to help

Thanks

Missing Changelog

I went looking for an easy way to view changes made to this project and noticed there is no changelog. I'd be more than happy to add a PR that includes a CHANGELOG but wanted to see if that's something you'd want added since that'd alter your releasing workflow a tad.

Let me know!

Problem matcher picks up issues that were ignored in the config file

Scenario:

1. Create config file with some ignores
2. Have a Dockerfile with some issues that should be ignored.
3. Run hadolint/hadolint-action
4. Job succeeds as findings are ignorred
5. hadolint still prints findings to stdout
6. Problem matcher picks them up and reports as error in GitHub UI

It's inconsistent and can be misleading. I'd like that problem matcher would skip the ignored findings.
Would require change to problem matcher or maybe hadolint.

How do I run multiple files

Locally I can run something like this hadolint docker/**/*Dockerfile to capture all the dockerfiles in a directory but that doesn't seem to work in the pipeline.

Any suggestions?

Fails on self-hosted runners

The same workflow runs fine on ubuntu-latest, but fails with hadolint: Dockerfile: openBinaryFile: does not exist (No such file or directory) on our self-hosted runner, any thoughts?

Release management: improve semantic versioning

Present tag $MAJOR_VERSION (in this case: v1) pointing to the last released version. In that case all action consumers can stick to the v1 version, without needing to keep track of version changes with dependabot and updating their caller actions each time.

See also https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-tags-for-release-management for details.

It should not stop the CI / exit = 0

I use this action to keep trace of best practices. It should not stop the CI . Is is possible ?

Thanks!

Support dockerfile's with extension

Can we add a support to add Dockerfile.* files for linter checks? Assuming such Dockerfile file format was officially added by docker community. It seems that currently only default Dockerfile's are only supported.

How do I ignore certain problems?

e.g. i would love to do something along these lines

name: Lint Dockerfile

on: push

jobs:
  linter:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v2

      - name: Lint Dockerfile
        uses: brpaz/hadolint-action@master
        with:
          dockerfile: "Dockerfile"
          ignore: "DL3013"

Who can I achieve that?

received unexpected HTTP status: 503 Service Unavailable

This may be an upstream problem, but FYI, I can't get my hadolint action to work anymore:

  Step 1/4 : FROM ghcr.io/hadolint/hadolint:v2.12.0-debian
  Head "https://ghcr.io/v2/hadolint/hadolint/manifests/v2.12.0-debian": received unexpected HTTP status: 503 Service Unavailable

[INVESTIGATED/TESTED] Configuration File Pathing Issue + Subsequent Issue

Please refer to PR #59 for detailed solutions.

ISSUES

• hadolint-action cannot receive configuration file properly
• Conflict infomation betweenREADME.md and action.yml
  • inputs.config.default is empty in action.yml, while README.md states otherwise
  • Default path stated in README.md would still encounter the above issue
• (Edited) the official hadolint/hadolint:latest container also suffers from configuration file issue

TEST CASES

• All done within GitHub Actions workflow
• All results in failure to receive configuration file

- uses: hadolint/[email protected]
  with:
    config: PATH

Substitute PATH with the followings:

hadolint.yaml
./hadolint.yaml
.hadolint.yaml
/home/runner/work/sandbox/sandbox/hadolint.yaml

INVESTIGATION

0. hadolint looks for configuration files via

$PWD/.hadolint.yaml
$XDG_CONFIG_HOME/hadolint.yaml
$HOME/.config/hadolint.yaml
$HOME/.hadolint/hadolint.yaml or $HOME/hadolint/config.yaml
$HOME/.hadolint.yaml

NOTE hadolint-action utilizes Docker container for execution

1. hadolint uses PWD and HOME environment variables
2. action.yml maps inputs.config to HADOLINT_CONFIG
3. Dockerfile points to hadolint.sh for entrypoint
4. hadolint.sh appends -c ${HADOLINT_CONFIG} to hadolint command
5. hadolint-action uses Docker with

docker run .. --workdir /github/workspace .. -v "/home/runner/work/sandbox/sandbox":"/github/workspace" ..

6. PWD=/ and HOME=/root inside the container

CONCLUSION

1. Since pwd inside the container isn't matching with PWD nor HOME, hadolint cannot find configuration file in usual places
2. Knowing pwd and -v for the container, we can edit PATH to be /github/workspace/hadolint.yaml for hadolint-action to use

SUGGESTION

• Document the usage in README.md accordingly (CONCLUSION.2)
  or
• Change PWD/HOME in Dockerfile to accommodate the differences
  or
• Prepend /github/workspace/ to the path of configuration file
  or preferably all of the above! :D
• Please consider adding MAJOR_VERSION tag for the release (#47)

Thank you!

Mention requirement to use checkout

I think the usage example should include the checkout action:

uses: actions/checkout@v2

Because otherwise you get this error trying to use hadolint:

hadolint: ./container/webui/Dockerfile: openBinaryFile: does not exist (No such file or directory)

How do I run hadolint on arm64?

For now, we can't run this action on arm64. Example

Looks like we have to wait for hadolint/hadolint#411

Creating this issue just to track the progress

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Missing package.json file.

A package.json file at the root of your project is required to release on npm.

Please follow the npm guideline to create a valid package.json file.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

How to update to hadolint 2.4.0?

I hope it's OK to ask questions via GitHub, couldn't find an alternative channel.

The hadolint 2.4.0 now supports the language-docker 10.0.0 with

• Fixed parsing of dockerfiles including a custom escape char

By the way, thank you @lorenzo and @m-ildefons very much for fixing this!

Would it be possible to update the action to use those latest?

Provide v2

GitHub Actions usually provide @v2 which would point to the latest @v2.x.y. Would be nice if hadolint would support this too :)

Dockerfile is a directory

- name: Run Hadolint on Dockerfiles
      id: hadolint
      uses: hadolint/[email protected]
      with:
        dockerfile: Dockerfile
        output-file: hadolintresult.json
        recursive: true
        no-fail: true
        format: json
        

I have some usecases in which Dockerfile is a directory and inside that we have dockerfile , but it fails as soon as it founds Dockerfile name directory instead it should ignore those

Fix for the same https://github.com/hadolint/hadolint-action/pull/82/files

Support -f parameter

Hi I would like to get from the action the report in checkstyle format in order to integrate hadolint with sonarqube, it would be nice to have this option available in the action as a parameter, also the output file name.

steps:
    - uses: brpaz/[email protected]
      with:
        dockerfile: Dockerfile
        format: checkstyle | json | etc
        outputPath: report.json

Thanks

Error: Unable to process command '::add-matcher::./tmp.nA8912gdP6/problem-matcher.json'

More often that not, the action fails seemingly randomly with the following error message:

Error: Unable to process command '::add-matcher::./tmp.nA8912gdP6/problem-matcher.json' successfully.
Error: Could not find a part of the path '/home/runner/work/XXXX/XXXX/tmp.nA8912gdP6/problem-matcher.json'.

Would it make sense to make the problem matcher opt-out?

`set-output` deprecation

Hi, running this action right now cause:

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Seems this is about this line

But have no idea how to fix it (

withBinaryFile: does not exist (No such file or directory)

I have the following Dockerfile

FROM golang:1.19 AS builder

ARG WDIR=myapp
ARG VERSION

COPY . ${WDIR}

WORKDIR ${WDIR}

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
    go build -a \
    --ldflags="-X main.buildVersion=${VERSION} -s -w" \
    -o /myapp

FROM gcr.io/myregistry/base/golang/alpine/1.19:stable

COPY --from=builder /myapp /bin/myapp

CMD ["/bin/myapp"]

This fails the lint with:

hadolint: ./myapp/Dockerfile: withBinaryFile: does not exist (No such file or directory)

The Dockerfile works as expected though

Jenkins Piplines unable to check multeple dockerfiles.

Hi All,

I am running Jenkins 2.416 with Hadolint version: Haskell Dockerfile Linter 2.12.0, When i run " hadolint dockerfiles//Dockerfile | tee hadolint_lint.txt"
dockerfiles/file1/Dockerfile:2:5 missing whitespace**
dockerfiles/file2/Dockerfile:2:5 missing whitespace

The output resulet in as per expectations. But when i run Jenkins pipline job, It start throwing error. Please find the error below.

+ hadolint dockerfiles-01/
hadolint: dockerfiles//Dockerfile: withBinaryFile: does not exist (No such file or directory)*

Please suggest.

Thanks & Regards
Pradeep Kumar

failure-threshold is not supported anymore

While trying to set the failure-threshold to error I get the following output:

Unexpected input(s) 'failure-threshold', valid inputs are ['entryPoint', 'args', 'dockerfile']

This makes hadolint default to info which causes the pipeline to fail on everything. This is happening with version 1.4.0