Add GitHub Actions workflow to lint Dockerfiles

[Hawazyn]

Description

This PR introduces a GitHub Actions workflow to lint Dockerfiles using Hadolint via Docker. It employs a matrix strategy to process predefined directories and uploads lint reports as artifacts.

Details

• Trigger: Runs on push to main, pull requests, and manual dispatch.
• Outcome: Successful execution indicates linting completed but does not ensure Dockerfiles are error-free.
• Artifacts: Lint reports are saved in JSON format for review.

Testing

• Verified workflow functionality in my forked repository under the Actions section.
• Confirmed graceful handling of missing directories or Dockerfiles.
• Validated accurate linting and artifact uploads.

Feedback is appreciated.

[baentsch]

Thanks for this new feature, @Hawazyn ! Looking at the linter output it seems quite some improvements on the Dockerfiles are possible. I don't understand, though, which ones are really necessary. Would such "really necessary" updates let the linter fail? In other words: Are our Dockerfiles "basically OK" as this new CI task passes (as it does right now)? Would it be worth while adding some explanation in this regard to the documentation, e.g., in the https://github.com/open-quantum-safe/oqs-demos/wiki/Contributing-guide or a new CONTRIBUTING.md file?

[Hawazyn]

@baentsch You’re right, and thanks for catching this! These errors don’t impact functionality at all—the Dockerfiles will work perfectly fine even if these errors show up. However, the linter is designed to enforce best practices. I’ll skip non-critical issues like pinning package versions and will add the URL at the top of the Dockerfile as a reference for clarity.

[baentsch]

I’ll skip non-critical issues

OK -- so if there were critical issues linting/this CI then would fail? If so, there indeed should be documentation what one has to do (locally, in one's dev environment) to get CI to pass again.

[ajbozarth]

@baentsch IIUC this CI will always pass as long as no errors occur. The linter just outputs a findings artifact that can then be reviewed to make changes.

I actually find this "false positive" deceptive when running on a PR, because on a glance a user might think the lint had no problems when they see the green check on the CI summary.

I believe it would be better to show a warning in the CI when lint fails rather than a "pass", this would make it non-blocking, but clear that there are lint issues. We would also want to clearly define which lint topics we care about and which are ignored entirely/

[Hawazyn]

@baentsch I’d like to start by apologizing for not clarifying the CI pipeline’s behavior earlier. Thanks for your patience.

The primary goal of this CI pipeline is to help ensure adherence to best practices in Dockerfiles, as outlined in the official Docker documentation. It does not validate functionality directly—that responsibility lies with other CI processes, which catch fundamental issues such as syntax errors or invalid instructions during the build process.

Currently, the CI passes as long as the linting process itself runs successfully, even if the linter identifies issues. These findings are logged as artifacts for contributors to review and address as needed. However, to provide more clarity and avoid the false impression that no linting issues exist, I’ll adopt @ajbozarth’s suggestion to display a warning in the CI summary if linting issues are found.

While the findings may include suggestions such as pinning versions of dependencies installed via apt-get or apk, I will configure the CI to skip these as they add unnecessary complexity and hinder progress, allowing the workflow to focus on actionable improvements.

I’d appreciate guidance on how, what, and where to document this process for contributors.