Support file filters based on changed files in PRs

[testworksau]

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.

[jbergstroem]

@testworksau said: but it scans everything / has an issue excluding files such as .json files, which causes a bit of noise for us

By default, it would only look for - and process - ./Dockerfile since this is the hadolint default.

You can pass what Dockerfiles (well, any file really; straight to Hadolint) you want it to process as part of using the action (See "dockerfile" input). Seems I don't have a test for this though, I will add one.

Would this cover your use case?

Edit: I guess it's worth mentioning you would want to use another action or just some bash scripting to pass what files have changed to this action.

[testworksau]

Thanks @jbergstroem

Edit: I guess it's worth mentioning you would want to use another action or just some bash scripting to pass what files have changed to this action.

This is basically what I'm after - it would be great if this was able to be built into the action itself, but in the meantime we will do as you suggest 👍🏼

[jbergstroem]

it would be great if this was able to be built into the action itself

I will consider it – the challenge is that I would have to make guesses on what is a Dockerfile or not. For instance, with some clients at previous work Docker-files would follow naming conventions (Dockerfile.node14, ..). I will definitely document it as part of the readme though (feel free to open a PR 😄)!

[jbergstroem]

Actually, come to think of it - this would probably be the most efficient way if you know exactly what files to cover. It avoids even being run to evaluate what files to look for compared to some of the github actions that would download npm packages just do do a glob over git diff.

on:
  pull_request:
    paths:
      - 'Dockerfile'

jobs:
  hadolint:
    runs-on: ubuntu-20.04
    name: "Hadolint"
    steps:
      - uses: actions/checkout@v2
      - uses: jbergstroem/hadolint-gh-action@v1

Keep in mind that you should avoid these patterns for evaluating build-time docker images tho!