Keep Docker check-only CI results separate from image builds

Bottom line: Accept a check-only result for its stated configuration review, then require separate evidence for building and publishing the intended image. Keep those outcomes distinct in the workflow and release checklist.

Source fact: documented behavior

The Validating build configuration with GitHub Actions documentation is the primary reference.

Docker build checks validate build configuration without running the build itself. For docker/build-push-action, the documented call: check setting runs checks and fails the workflow when check warnings are detected. The guide also documents a Bake check target and a separate build-and-push step in its workflow example.

What the source does not establish

This article reviews the check-only/build distinction. It does not define every available check, prescribe a particular warning fixture or establish that an image is runnable, tested or published after configuration validation. Confirm the installed actions and required release steps rather than inferring broader acceptance from a green check.

Applicability questions

• Which step performs only configuration checks?
• What actual warnings should cause investigation?
• Which separate step produces the intended image?
• What evidence establishes the expected registry result rather than merely job success?

DSE recommendation: name the outcome of each CI stage

DSE recommends naming the check stage for configuration validation and giving image construction and publication separate checklist entries. Have the pipeline owner identify the responsible step for each outcome. Keep a failed check visible rather than disabling validation simply to recover an unrelated publish step.

Inspect the selected action inputs or Bake target in the managed workflow. Mark the check-only invocation clearly and review which target it addresses. Preserve the distinction when a shared workflow is reused by several repositories. Require the caller to explain what later step is responsible for the actual deliverable.

Assign warnings to a review process appropriate to the installed checks. Ask the build owner to explain the underlying configuration before approving a change or an exception. Do not invent a warning name, assume every warning represents a vulnerability or replace the check with an unreviewed automatic rewrite.

Tie the later build result to the intended source revision and approved image identity. Review publication evidence independently of the check report. Keep application tests and deployment approval as their own requirements, so a successful configuration check cannot silently satisfy all release criteria.

Verification and evidence

Proposed verification: prepare a harmless test repository with a known configuration accepted by the installed documented checks. Retain the check-only invocation and actual check report. Separately inspect whether the planned build and publication steps ran and what artifacts they produced.

For a warning case, have the owner choose a benign fixture supported by the installed check set and predict the expected outcome before running it. Compare the check report with the workflow result without prescribing an unverified error message. Retain source revision, selected target, action configuration and separate build/publication observations. No proposed test result should be entered as completed release evidence.

Official references

• Validating build configuration with GitHub Actions — Docker Docs.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.