D4.5 promises "nothing partial ships" and covers a failed build. Moving the package push out of the leaf (#1162, released in 2.0.536) makes a failed push after a cut release reachable, and the guarantee does not cover it.
Reported by the ptr727/Utilities session while adopting the fix, and verified here against main at 1fe2537.
The ordering that makes it reachable
github-release is a job inside build-release-task.yml (.github/workflows/build-release-task.yml:283), while the caller stub's publish-nuget / publish-pypi job carries needs: [validate, publish] and therefore runs after the whole task, including that release job.
So a token-exchange failure, a registry outage, or a trusted-publishing policy mismatch now leaves a published GitHub release and a git tag for a version that never reached the registry, with the repo's release notes and README badge implying it shipped.
Under the previous shape the push happened inside build-nuget and github-release needed it, so a failed push meant no tag and no release. That property was lost as a side effect of moving the push, and nothing recorded it.
Why the ordering should probably not change
The push has to be in the publishing repository's own publisher, because trusted publishing validates the OIDC job_workflow_ref claim, which is the whole point of #1162. That constraint forces the push after the task, and therefore after github-release. So this is a documentation gap rather than a wiring bug.
It is also recoverable: re-running the publisher is idempotent through the release-exists gate plus --skip-duplicate.
What is missing
D4.5 still reads as "nothing partial ships" while a partial ship is now possible. Either a sentence in D4.5 naming this case and its recovery, or its own D-number covering "a registry push can fail after the release is cut, and here is what that looks like and how to recover".
The Utilities session recorded it in its publish-nuget job comment as a local stopgap, which is the wrong home for a fleet guarantee.
Related
The same promotion's D4.5 edit added the split publish job's own gate for a failed build, which is what made the push half visible by contrast.
D4.5 promises "nothing partial ships" and covers a failed build. Moving the package push out of the leaf (#1162, released in 2.0.536) makes a failed push after a cut release reachable, and the guarantee does not cover it.
Reported by the ptr727/Utilities session while adopting the fix, and verified here against
mainat1fe2537.The ordering that makes it reachable
github-releaseis a job insidebuild-release-task.yml(.github/workflows/build-release-task.yml:283), while the caller stub'spublish-nuget/publish-pypijob carriesneeds: [validate, publish]and therefore runs after the whole task, including that release job.So a token-exchange failure, a registry outage, or a trusted-publishing policy mismatch now leaves a published GitHub release and a git tag for a version that never reached the registry, with the repo's release notes and README badge implying it shipped.
Under the previous shape the push happened inside
build-nugetandgithub-releaseneeded it, so a failed push meant no tag and no release. That property was lost as a side effect of moving the push, and nothing recorded it.Why the ordering should probably not change
The push has to be in the publishing repository's own publisher, because trusted publishing validates the OIDC
job_workflow_refclaim, which is the whole point of #1162. That constraint forces the push after the task, and therefore aftergithub-release. So this is a documentation gap rather than a wiring bug.It is also recoverable: re-running the publisher is idempotent through the release-exists gate plus
--skip-duplicate.What is missing
D4.5 still reads as "nothing partial ships" while a partial ship is now possible. Either a sentence in D4.5 naming this case and its recovery, or its own D-number covering "a registry push can fail after the release is cut, and here is what that looks like and how to recover".
The Utilities session recorded it in its
publish-nugetjob comment as a local stopgap, which is the wrong home for a fleet guarantee.Related
The same promotion's D4.5 edit added the split publish job's own gate for a failed build, which is what made the push half visible by contrast.