Repository navigation
ci: the release workflow runs every lane of dotnet.yml on the tagged commit before it packs - #537
CaffeinatedCoder wants to merge 1 commit into
Conversation
…commit before it packs (#342) release.yml ran the suite once, on PostgreSQL 16, and relied on the commit's pull request for PostgreSQL 18, the own-feed smoke test and, on release/10.x, the EF Core float legs. Nothing ties a tag to a commit whose pull request or push run was green. - dotnet.yml gains workflow_call, and release.yml a `ci` job that uses it. `verify` needs `ci` and loses its own test step. - dotnet.yml's concurrency group gets a `dotnet-` prefix. Called from the release workflow it was `Release-<ref>`, which GitHub compares without case to release.yml's own `release-<ref>`: the called jobs would have waited for their caller. - ReleaseWiringConventionTests holds both: the call and the dependency, and that the two groups cannot be equal. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Dry runs of the release workflow (2026-11-11)Both started with This branch, as it is (run 42977816466): success in 5 minutes. No deadlock between the two concurrency groups.
A seeded failing integration test (run 42978030642), on a throwaway branch with one extra test in the infinity-disabled integration project that calls
So a failing lane stops the release before anything is packed. A first seeded run (42977824183) proved nothing and is not counted: its seed changed nullable flow in an existing test, the build failed with CS8602, and every job failed for that reason. The throwaway branch is deleted. Not shown here: the EF Core float legs, which only |
Closes #342
Problem
release.yml'sVerify and packjob ran the suite once, on the default integration image, so a release was tested on PostgreSQL 16 only. PostgreSQL 18, the consumer smoke test against a feed of its own and, onrelease/10.x, the EF Core float legs were left to the commit's pull request. Nothing ties a tag to a commit whose pull request, or whose push run, was green.Change
dotnet.ymlgainsworkflow_call.release.ymlgains a jobcithat uses./.github/workflows/dotnet.yml, andverifyneeds it.verifyloses its owndotnet teststep:ciran the whole suite on the same commit, the conventions project included. It keeps the tag check, the pack, the smoke test againstdistand the SBOMs.dotnet.yml's group is nowdotnet-${{ github.workflow }}-${{ github.ref }}. In a called workflowgithub.workflowis the caller's name, so the old group wasRelease-<ref>there, and GitHub compares group names without case: that is the grouprelease.ymlitself holds (release-<ref>). The called jobs would have waited for their own caller.ReleaseWiringConventionTests, two tests:TheReleaseWorkflow_RunsEveryLaneBeforeItPacks:dotnet.ymlis callable, a job inrelease.ymluses it, andverifyneeds that job.TheCalledBuildWorkflow_NeverSharesTheReleaseWorkflowsConcurrencyGroup: both groups evaluated for the release workflow's name and one ref, compared without case.A mistyped tag now fails after the lanes rather than before them. That costs one CI run and nothing else: the ruleset forbids moving or deleting a
v*tag, so that tag was lost either way.Tests
Conventions: 419 passed. Each guard proven by seeding on the committed change, then restored:
${{ github.workflow }}-${{ github.ref }}TheCalledBuildWorkflow_…: "dotnet.yml's concurrency group is 'Release-refs/tags/v1.2.3', and release.yml holds 'release-refs/tags/v1.2.3'"needs: ciremoved fromverifyTheReleaseWorkflow_…: "The verify job (needs: nothing) does not wait for 'ci'"workflow_callremovedTheReleaseWorkflow_…: "dotnet.yml has no workflow_call trigger"ciuses another workflowTheReleaseWorkflow_…: "No job in release.yml uses ./.github/workflows/dotnet.yml"Two dry runs of the release workflow are in a comment below: this branch as it is, and a throwaway branch with a seeded failing integration test.
The cherry-pick to
release/10.xfollows in its own PR; the dry run there is the one that shows the float legs.🤖 Generated with Claude Code