Skip to content

hadolint has never run, and its dockerfile: input is a glob it cannot expand #52

Description

@acamarata

Dockerfile linting has never run, and would fail if it did

.github/workflows/hadolint.yml has never executed once. Its only run in history is the one accidentally triggered on 2026-08-26 by the PR that added the workflow to its own paths: list.

That run failed immediately:

hadolint: **/Dockerfile: withBinaryFile: does not exist (No such file or directory)

Two independent defects

1. The path filter never matched, so it never ran.

The workflow was gated on **/Dockerfile, **/Dockerfile.*, **/.hadolint.yaml but did not list itself, so no edit to the workflow could trigger it. Combined with defect 2 it meant the job was configured, visible in the Actions list, and producing exactly zero signal.

2. dockerfile: is given a glob, but hadolint does not glob.

The action is invoked with dockerfile: "**/Dockerfile". hadolint treats that as a literal filename and tries to open a file called **/Dockerfile, which does not exist. This fails regardless of how many real Dockerfiles the repo has.

This repo does have real Dockerfiles that have consequently never been linted.

Fix

Either point it at the actual file(s):

with:
  dockerfile: Dockerfile      # or the real path

or let the action walk the tree:

with:
  recursive: true

recursive: true is the better fit here since more than one Dockerfile may exist, and it keeps working when one is added.

Sequencing caution

Fixing the invocation will make hadolint lint Dockerfiles that have never been linted, so expect real findings on the first green run. Worth fixing the invocation and the resulting lint errors together, rather than landing the fix and turning main red.

The current failure-threshold: error with ignore: DL3008,DL3009,DL3015 suggests the intent was a fairly permissive gate, so the fallout is likely small.

Context

Found during an org-wide sweep for gates whose success condition is unreachable or trivially satisfiable. The same hadolint.yml misconfiguration exists in both nchat and clawde. Related instances found in the same sweep: a required status check named nself-ci that no workflow produced (7 repos), a postgres readiness check satisfied by the temporary initdb server, a quarterly cron firing ~10x per quarter, a Desktop E2E suite gated on a directory that does not exist, and nself-org/cli#268 / nself-org/cli#270.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions