Fix CI: ignore hadolint DL3066 for the named user in the Dockerfile - #2313
Merged
Conversation
hadolint 2.15.0, pinned by hadolint-action v3.4.0, reports DL3066 on `USER ${USERNAME}`. The action's default failure-threshold is info, so the finding fails the job and skips the formatting and test steps after it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Currently, CI is red on
main, and it blocks every open PR from going green. TheLint Dockerfilestep fails withDockerfile:43 DL3066 info: Non-numeric user-id may not be resolvable by host system, pointing atUSER ${USERNAME}.This PR adds
DL3066to the ignore list in.hadolint.yaml. The image runs as the namednodeuser that thenodebase image already provides, so the non-numeric user-id resolves inside the container. That's by design, not something to fix in the Dockerfile.Root cause
#2311 bumped
hadolint/hadolint-actionto v3.4.0, which pinshadolint:v2.15.0-debian. That version reports DL3066 where the previous one did not. The action's defaultfailure-thresholdisinfo, so an info-level finding is enough to fail the job. #2310, the commit right before it, has a green run, which confirms the bump is what changed.The step also short-circuits the rest of the job:
Check formattingandRun testsare skipped when the Dockerfile lint fails, so no PR gets its tests run in CI until this lands.Why the ignore, and not a higher threshold
Raising
failure-thresholdaboveinfowould also fix the red build, but it would stop info-level findings from blocking anything else, for a single rule we disagree with. The ignore entry is narrower.By the way, this rule looks like it was short-lived upstream: hadolint 2.15.1 no longer reports DL3066 on this Dockerfile, only 2.15.0 does. So a future action bump may make the entry unnecessary. It's harmless to keep either way, and I'd rather not wait on a release we don't control.
How to test
It exits
0. Onmainthe same command reports DL3066 and exits1.It reports DL3003 and SC2164, and exits
1.npm run format:checkpasses (172 files, no fixes applied), andnpm run test:coveragepasses (40 test files, 349 tests).Note:
npm run lintexits1on my machine, onmaintoo, from a knip "Unlisted binaries: playwright" report. It's a local environment difference, not from this change; theRun lintstep passed in CI on the failing run.