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?

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

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.

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)

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"

Hadolint --config option?

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?

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?

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.

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?

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!

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)

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

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

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

🚨 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 📦🚀

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.

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

Thanks!

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 (

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

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

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

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.

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

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?

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

- 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

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?

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.

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

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!