Lint the entrypoint and the Dockerfile on every pull request - #38
Open
tigerblue77 wants to merge 1 commit into
Open
tigerblue77 wants to merge 1 commit into
tigerblue77 wants to merge 1 commit into
Conversation
Until now nothing in this repository checked either file beyond whether they built. That is a weak test: `docker/run.sh` has held for six years and would still pass shellcheck's stricter POSIX family cleanly, but a future edit to it would not get that for free just because the file did once. Same for the Dockerfile — building it proves the layers resolve, not that they are written the way the image actually wants them. Both linters run clean against what is on master today: shellcheck reports nothing on `docker/run.sh` (`-x` for when it ever starts sourcing something), and hadolint reports one warning, DL3041, on the single `dnf install` line that pulls in `passwd`/`procps`/`kmod`/`tar`/`which`/`crypto-policies-scripts`. That one is silenced in `.hadolint.yaml` with a reason rather than worked around: this image does not pin OS package versions anywhere, on purpose, and the base image and its own repos are what "supported" tracks here — a frozen NEVRA for six packages would need bumping by hand for no reason connected to this Dockerfile. Both jobs are pinned the same way the rest of the workflows in this repository already are — `actions/checkout@v7.0.1`, `hadolint/hadolint-action@v3.5.0` checked against that action's own tags rather than assumed — and picked up automatically by the existing `github-actions-all` dependabot group, no new ecosystem entry needed. Assisted-by: Claude Signed-off-by: Tigerblue77 <37409593+tigerblue77@users.noreply.github.com>
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
1 participant
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.
Nothing in this repository checked either file beyond whether they built. That is a weak test:
docker/run.shhas held for six years and would still pass shellcheck's stricter POSIX family cleanly, but a future edit to it would not get that for free just because the file did once. Same for theDockerfile— building it proves the layers resolve, not that they are written the way the image actually wants them.Both jobs are green against master today, unmodified. Shellcheck reports nothing on
docker/run.sh(-xso it follows asource/.the day the entrypoint ever grows one). Hadolint reports one finding, DL3041, on the singlednf installline that pulls inpasswd/procps/kmod/tar/which/crypto-policies-scripts— silenced in.hadolint.yamlwith a reason rather than worked around: this image does not pin OS package versions anywhere, on purpose, and the base image and its own repos are what "supported" tracks here, so a frozen NEVRA for six packages would need bumping by hand for no reason connected to thisDockerfile.Both actions are pinned the way the rest of this repository's workflows already are —
actions/checkout@v7.0.1, andhadolint/hadolint-action@v3.5.0checked against that action's own tags rather than assumed, since it publishes no floatingv3. Picked up automatically by the existinggithub-actions-alldependabot group; no new ecosystem entry needed.One thing worth flagging myself:
hadolint/hadolint-actionalways exportsHADOLINT_FAILURE_THRESHOLDat its owninfodefault whatever the step's input, but hadolint 2.15.1's own precedence is CLI > config file > environment, so.hadolint.yaml'swarningstill wins — confirmed against this action's pinned binary rather than assumed. Documented in the workflow so nobody "fixes" it by adding afailure-thresholdinput, which would just duplicate the config and hide the real value from a localhadolint Dockerfilerun.Assisted-by: Claude
Signed-off-by: Tigerblue77 37409593+tigerblue77@users.noreply.github.com