Block a partial publish when a build fails

.github/workflows/build-release-task.yml

@@ -103,10 +103,16 @@ jobs:
       assembly_file_version: ${{ needs.get-version.outputs.AssemblyFileVersion }}
       assembly_informational_version: ${{ needs.get-version.outputs.AssemblyInformationalVersion }}
 
+  # The terminal publish target, so it needs every other build (D4.5).
+  # The image builds from source and consumes no executable artifact, so nothing else forces the ordering.
+  # Without it a failed build-executable skips github-release while the image still pushes and `latest` moves.
+  # That is a partial publish: an image with no release.
+  # `!failure()` is what blocks it, since a failed upstream build must stop the push where a skipped one must not.
+  # `validate` is skipped on smoke, which is the skip that must still build.
   build-docker:
     name: Build Docker job
-    needs: [get-version, validate, validate-release]
-    if: ${{ !cancelled() && needs.get-version.result == 'success' && needs.validate-release.result == 'success' && (needs.validate.result == 'success' || needs.validate.result == 'skipped') }}
+    needs: [get-version, validate, validate-release, build-executable]
+    if: ${{ !failure() && !cancelled() && needs.get-version.result == 'success' && needs.validate-release.result == 'success' && (needs.validate.result == 'success' || needs.validate.result == 'skipped') }}
     uses: ./.github/workflows/build-docker-task.yml
     secrets: inherit
     with:

WORKFLOW.md

@@ -168,6 +168,7 @@ The required behaviors, organized by domain. Each is a **MUST**, stated as input
 - **D4.2 Tag the built commit.** Output: the release `target_commitish` is the built commit's SHA (NBGV's commit id), never `github.sha` or a moving branch ref. *Prevents: the tag landing on the default branch instead of the built tree.*
 - **D4.3 Release contents.** Output: every release is a tag on the built commit plus the auto source zip, README, and LICENSE; file-producing targets attach `release-asset-*`; `prerelease` equals `branch != default`. A no-file-target repo that uses the release task (Docker-only, PyPI-only) reaches the tag-only shape **only** with `expect_release_assets: false` set by the caller (which relaxes `fail_on_unmatched_files` and skips the asset download). With the default `true` and no assets the release-create step fails. A source-only repo reaches the same shape through its inlined `action-gh-release` instead, with no release task or `expect_release_assets`.
 - **D4.4 No-op republish.** Input: a re-run whose version is unchanged. Output: nothing is re-pushed, because the release-create step is skipped when the tag exists (refreshed only on `workflow_dispatch`), and the paired asset-delete is skipped with it. Registry pushes are no-ops. The NuGet/PyPI publish steps are **not** statically gated on existence. They run and the **server** dedupes (`dotnet nuget push --skip-duplicate` turns a 409 into success; PyPI `skip-existing: true`). **Docker always re-pushes** the image (base-image refresh), independently of the release-create skip, within the same run. *Prevents: duplicate releases and wasted pushes.*
+- **D4.5 A build failure blocks every publish target.** Input: a real publish where one enabled build fails. Output: nothing publishes. `github-release` needs every build, so a failed build skips it (no tag, no release), and the terminal registry pusher (Docker) needs every other build and guards its `if` with `!failure() && !cancelled()`, so a failed build skips docker too (no image push) while a disabled or unchanged target (skipped, not failed) still lets docker build on smoke. *Prevents: a partial publish, e.g. a Docker image pushed while the executable build failed and no release was cut.* A repo pushing two registry targets at once would need a build/publish split behind an all-builds gate, which none does today.
 
 ### D5 - Resource Cleanup