Add Hadolint for Dockerfiles

[chandwanitulsi]

Assisted-by: Cursor/Gemini

[qodo-for-releng]

PR Summary by Qodo

Add Hadolint linting for Dockerfiles via tox

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Add Hadolint configuration for UBI-based Dockerfiles and trusted registries.
• Wire Hadolint into tox as a mandatory static check targeting key Dockerfiles.
• Standardize Dockerfile linting thresholds to fail only on errors.

Diagram

graph TD
  A["CI / Developer"] --> B["tox (static)"] --> C["tox env: hadolint"] --> D["hadolint (hadolint-py)"] --> E["Dockerfiles"]
  F[".hadolint.yaml"] --> D

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Run Hadolint via GitHub Action (container)

• ➕ No Python dependency management (uses hadolint image)
• ➕ Consistent versioning and behavior across runners
• ➕ Can annotate PRs with inline findings
• ➖ Splits lint orchestration between tox and CI
• ➖ May require additional CI config and maintenance

2. Use pre-commit hook for hadolint

• ➕ Fast feedback before CI; easy local adoption
• ➕ Standardized developer workflow across repos
• ➖ Not everyone installs/uses pre-commit unless enforced
• ➖ Still needs CI enforcement to prevent bypass

Recommendation: Keeping hadolint in tox is a solid choice if tox is the canonical aggregator for static checks in this repo. Consider optionally adding a CI job (or pre-commit) later for better developer ergonomics and PR annotations, while retaining the tox env as the single source of truth for the command and file targets.

Files changed (2) +20 / -2

Enhancement (1) +10 / -2

tox.iniAdd hadolint tox environment and include in static checks +10/-2

Add hadolint tox environment and include in static checks

• Adds a new mandatory tox environment that installs hadolint-py and runs hadolint with an error-only failure threshold. Updates envlist and the static label group so Dockerfile linting participates in standard static runs.

tox.ini

Other (1) +10 / -0

.hadolint.yamlAdd repository Hadolint configuration +10/-0

Add repository Hadolint configuration

• Introduces a hadolint config tailored for UBI-based Dockerfiles. Ignores a small set of rules and allow-lists Red Hat registries as trusted sources.

.hadolint.yaml

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:46 PM UTC · Completed 9:59 PM UTC

Commit: 4617ed8 · View workflow run →

[qodo-for-releng]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Hadolint missing in GH mapping 🐞 Bug ☼ Reliability

Description

tox.ini defines a new [testenv:hadolint] and marks it as Mandatory, but the [gh-actions]
python-version mapping does not include hadolint, so tox-gh-actions-based environment selection
will not run the new Dockerfile lint. This undermines enforcement of the new lint in CI paths that
rely on the [gh-actions] mapping.

Code

tox.ini[R111-114]

+[testenv:hadolint]
+description = Dockerfile linting [Mandatory]
+skip_install = true
+deps =

Relevance

●●● Strong

Ensures new mandatory hadolint tox env actually runs in CI; aligns with PR intent and enforcement.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The repo’s GitHub Actions workflow installs tox-gh-actions, and tox.ini has a [gh-actions]
mapping listing the environments to run for each Python version; that list omits hadolint even
though the PR adds a new [testenv:hadolint] and includes it in envlist/static label.

tox.ini[4-16]
.github/workflows/run_tox.yml[11-43]
tox.ini[111-118]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
A new `hadolint` tox environment was added and labeled as mandatory, but it is not included in the `[gh-actions]` mapping that tox-gh-actions uses to select which tox envs to run per Python version. As a result, Dockerfile linting can be skipped in GitHub Actions runs that depend on that mapping.

### Issue Context
The workflow installs `tox-gh-actions`, and `tox.ini` already contains a `[gh-actions]` section enumerating envs per Python version. The new env should be added there to ensure consistent CI enforcement.

### Fix Focus Areas
- tox.ini[12-16]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-for-releng]

1. Hadolint missing in gh mapping 🐞 Bug ☼ Reliability

tox.ini defines a new [testenv:hadolint] and marks it as Mandatory, but the [gh-actions]
python-version mapping does not include hadolint, so tox-gh-actions-based environment selection
will not run the new Dockerfile lint. This undermines enforcement of the new lint in CI paths that
rely on the [gh-actions] mapping.

Agent Prompt

### Issue description
A new `hadolint` tox environment was added and labeled as mandatory, but it is not included in the `[gh-actions]` mapping that tox-gh-actions uses to select which tox envs to run per Python version. As a result, Dockerfile linting can be skipped in GitHub Actions runs that depend on that mapping.

### Issue Context
The workflow installs `tox-gh-actions`, and `tox.ini` already contains a `[gh-actions]` section enumerating envs per Python version. The new env should be added there to ensure consistent CI enforcement.

### Fix Focus Areas
- tox.ini[12-16]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[lipoja]

@chandwanitulsi What about this comment?

[fullsend-ai-review]

Review

Findings

Low

• [edge-case] tox.ini:115 — The hadolint command uses --failure-threshold error, so only error-level findings will fail the build. Warning-level findings (e.g., missing SHELL instructions, curl-without-checksum) will be printed but not block CI. Consider raising to --failure-threshold warning once existing Dockerfile warnings are resolved or added to the ignore list.

• [scope-undocumented-choice] .hadolint.yaml:3 — The four ignored Hadolint rules (DL3003, DL3013, DL3041, DL4006) lack inline comments explaining why they are suppressed. Adding brief justifications (e.g., UBI-specific constraints) would help future contributors distinguish permanent exceptions from temporary workarounds.

• [file-naming-convention] .hadolint.yaml — The existing yamllint config uses .yamllint.yml while the new hadolint config uses .hadolint.yaml. This is cosmetic — .hadolint.yaml is hadolint's default config filename, and renaming would require an explicit --config flag.

• [stale-doc] README.md:51 — The README instructs developers to run tox -e black,flake8 to verify code standards, but the static label now includes black, flake8, yamllint, mypy, hadolint. Consider updating to tox -m static to capture all static linters. (Note: this gap predates this PR.)

---

Labels: PR adds Dockerfile linting tool (hadolint) to CI pipeline via tox

[fullsend-ai-review]

[low] scope-undocumented-choice

The four ignored Hadolint rules (DL3003, DL3013, DL3041, DL4006) lack inline comments explaining why they are suppressed.

Suggested fix: Add inline comments explaining why each rule is ignored (e.g., UBI-specific constraints, base image requirements).

[lipoja]

@chandwanitulsi What about this comment?