Hadolint 2.9.0 outputs 2.9.0-no-git which would lead to unecessary downloads for certain scenarios. We should improve version matching to avoid this.

..for instance, filtering on what Dockerfiles to trigger a lint with.

Like many other github actions, this repo should also support passing a custom version of the binary for use. This would be implemented in the action itself, so testing needs to be consiered properly (currently, testing is done via a second repository triggered while landing to the main branch).

Updating hadolint

1. edit action.yml (or let renovate manage it)
2. update README.md (cannot be done by renovate unless self-hosted with postupdate scripts) to update default value #116

Updating the action

1. update lib/hadolint.sh and commit said change
2. draft a new release (autodraft suggests changelog and a new tag)
3. review
4. release

The upcoming approach basically assumes that the glob works, but that's it. A better test would be to verify that the files that are tested are the ones we expect by checking output from hadolint and matching the filenames.

Refs: #82.

If there are changes to action.yml, these needs to be tested to make sure that it doesn't break (see it as e2e via the action environment).

Sarif is a json format that provides a finer grained way of showing errors, warnings and so on. The issues found are also shown on the security page which might interest a fair amount of people.

Based on a JSON template there might be a not-so-painful way of having jq emit a sarif-friendly document that github can consume.

For a repo with collection of Dockerfile-s structured like this:

/a/x/Dockerfile
/a/y/Dockerfile
/a/z/Dockerfile

the following workflow with shell expansion

jobs:
  hadolint:
    name: Dockerfiles
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: jbergstroem/hadolint-gh-action@v1
      with:
        dockerfile: "**/Dockerfile"

fails with

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

Is the recursive look-up for multiple Dockerfile-s even supported?
I failed to find any note on that in the docs.

Instead of overriding the path in a shell environment, we can allow the user to pass custom direct paths to hadolint and jq instead. This makes it easier to work in stricter environment where there may be limits to what can be overridden or changed.

Currently not covered by test suite

Create a test that showcases that we can pass any amount of files to the action. Refs #33.

I initially considered seeing this as ABI breaking but I'm on the fence since I've been more or less emulating the same behavior.

It could backfire if upstream decides to change things radically (output formats, flags, ..). Will keep this open for a bit and see what others thinl.

- uses: jbergstroem/hadolint-gh-action@v1
  id: hadolint
  with:
    dockerfile: ./Dockerfile
    #output_format: sarif

- name: Debug
  shell: bash
  run: |
    echo "${{ steps.hadolint.outputs.hadolint_version }}"
    echo "${{ steps.hadolint.outputs.hadolint_gh_action_version }}"
    echo "${{ steps.hadolint.outputs.hadolint_output }}"

Produces:
Run echo "2.12.0"
echo "2.12.0"
echo "1.12.0"
echo ""

In other words: the hadolint_output output variable is empty, no matter which output_format is specified.
It looks like it's being caused by:

Possible solution:
change
echo "hadolint_output=${OUTPUT//$'\n'/'%0A'} >> \$GITHUB_OUTPUT"
to
echo "hadolint_output=${OUTPUT//$'\n'/'%0A'}" >> "${GITHUB_OUTPUT}"

Reasoning:

• no need to manually maintain github relases for dependencies
• simpler to use and manage compared to dependabot

This bugs me:

Running tests in test/e2e.sh
	Running test_annotate ... SUCCESS ✓
	Running test_bash_glob_expansion ... SUCCESS ✓
	Running test_custom_config ... SUCCESS ✓
	Running test_custom_dockerfile_path ... SUCCESS ✓
	Running test_custom_hadolint_path ... SUCCESS ✓
	Running test_custom_output_format ... SUCCESS ✓
	Running test_default_hadolint_config ... SUCCESS ✓
	Running test_default_path ... SUCCESS ✓
	Running test_default_path_with_dockerfile ... SUCCESS ✓
	Running test_disable_annotate ... SUCCESS ✓
	Running test_multiple_dockerfiles ... SUCCESS ✓
	Running test_output_with_nonzero_exit ... SUCCESS ✓
	Running test_override_errorlevel ... SUCCESS ✓
	Running test_version_output ... ::add-matcher::~/.github/problem-matcher.json

SUCCESS ✓
Running tests in test/unit.sh
	Running test_output_hadolint_version ... SUCCESS ✓
	Running test_validate_annotate ... SUCCESS ✓
	Running test_validate_error_level ... SUCCESS ✓
	Running test_validate_invalid_annotate ... SUCCESS ✓
	Running test_validate_invalid_error_level ... SUCCESS ✓
	Running test_validate_invalid_output_format ... SUCCESS ✓
	Running test_validate_output_format ... SUCCESS ✓
Overall result: SUCCESS ✓

The issue is how stdout is managed since I redirect output to emulate the CI environment.

It seems like error_level: 2 always bails:

$ dockerfile=../mariadb-alpine/Dockerfile error_level=2 ./hadolint.sh
::set-output name=hadolint_version::2.4.0-no-git
$ echo $?
1

It would likely look cleaner to extract hadolint version from a file instead of inline in a github action. That way, bumps are more visible to a user.

Mention that we aim to follow upstream semver plus our own, ultimately leading to a consistent experience for the user (being able to pin to major, min & patch)

We have a single repository with multiple Dockerfiles, and our pipeline only builds those files that are modified.

My understanding is that running this tool would result on all Dockerfiles being scanned in a pull request, regardless of whether they belong to the PR or not. If that's the case, it would be good if this tool had support to specify a filter; that is, to allow us to specify whether to scan every Dockerfile in the repo, or only those that are part of the PR (added, modified, copied, renamed, and / or changed).

We are currently using reviewdog/action-hadolint@v1 which has its own filtering options, but it scans everything / has an issue excluding files such as .json files, which causes a bit of noise for us:

https://github.com/reviewdog/reviewdog#file

We'd like to switch to this action in any case as the output format options look interesting.

I'm currently using this wonderful action and I'm encountering a minor bug.

To design an action for a group of projects, I wanted to use hadolint-gh-action in two different steps where the first works on directory docker and the second on .devcontainer. However, if one wants to use the action twice, there is an issue because of mkdir ${{ github.action_path }}/bin in the action.yml file. Since it already exists, you end up with the following error mkdir: cannot create directory ‘/home/runner/work/_actions/jbergstroem/hadolint-gh-action/v1/bin’: File exists.

A quick fix would be to use option -p of mkdir to avoid throwing an error is the path exists.

I'm trying to simple print all lint failures into the CI log rather than using annotations, mostly for consistency.

But whatever I do I can't seem to get the output to work:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Docker Lint
        id: docker-lint
        uses: jbergstroem/hadolint-gh-action@v1
        with:
          annotate: false
          error_level: 2
          output_format: tty
          dockerfile: "**/Dockerfile"
      - name: Docker Lint Output
        if: always()
        run: echo ${{ env.OUTPUT }}
        env:
          OUTPUT: ${{ steps.docker-lint.outputs.hadolint_output }} # also tried using outputs directly in echo

Can you let me know if I am using this as designed or if I'm missing something here?

Btw it would be nice if the default behavior (with annotations off and no output format set) for the action to print all errors into the log rather than hiding it.

The parser for jq currently assumes that input to exit_if_found_in_json is a single value. jq natively supports traversing arrays as long as it understands that the value passed is an array. Find a way to pass string or array natively to avoid an extra loop.

If a test suite fails we can provide better information with the fail directive.

Since version 2.12.0 this action always fails on our self-hosted runners with the following output:

> Run jbergstroem/hadolint-gh-action@v1
  with:
    dockerfile: ./Dockerfile
    error_level: 0
    annotate: true
    version: 2.12.0
> Run /runner/_work/_actions/jbergstroem/hadolint-gh-action/v1/install.sh
  /runner/_work/_actions/jbergstroem/hadolint-gh-action/v1/install.sh
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    version: 2.12.0
mv: cannot move '/tmp/hadolint' to '/usr/local/bin/hadolint': Permission denied
1
Error: Process completed with exit code 1.

For context, the self-hosted runner is using this Docker image:
summerwind/actions-runner-dind:v2.312.0-ubuntu-22.04