Repository navigation
Conversation
The job already runs on windows-latest and *builds* net48, so a compile break there would be caught - but the only test steps are net8.0 and net10.0. That gap matters specifically because the `*.output.netfx.*` interceptor goldens are compared at **test** time: a netfx golden can be wrong while CI stays green, which is exactly the state #214, #216 and #220 have left main in (all three touched those files, and none of them could be exercised on Linux). One more step, same job, same image, same filter.
mgravell
added a commit
that referenced
this pull request
Sep 11, 2026
…CI (#222) * Target 1.1.0, fix the release-tag pattern, and report the version in CI Three things, all in service of cutting 1.1.0 cleanly. **Land on 1.1.0.** versionHeightOffset goes -1 -> -3. The offset is a fixed shift, not a pin: height counts commits since the `version` property changed, and two more have landed since (#221, and this one), so -1 would compute 1.1.1. Editing versionHeightOffset does *not* reset the height - verified, height stays 3 - so the offset has to absorb the drift. -3 puts this commit at exactly 1.1.0, which is what main will compute once this squash-merges (one commit on top of 78f0fc7 either way). **Fix the release-tag pattern**, which has never worked. publicReleaseRefSpec requires `^refs/tags/v\d+\.\d+`, but every tag this repo has ever cut is unprefixed - 1.0.52, 1.0.48, 1.0.45 and so on - so the regex cannot match any of them. Checking out the real 1.0.52 tag and asking nbgv gives `1.0.52-g7a36975e31`, PublicRelease False: a tag-triggered build has always produced a -g suffixed version, and the packages that shipped must have come from main builds instead. Relaxed to `v?`, so both spellings work; at an unprefixed 1.1.0 tag nbgv now reports a clean 1.1.0, PublicRelease True. Same fix, same reason, as StackExchange.Redis 611e478. **Report the computed version in CI**, modelled on StackExchange.Redis's CI.yml: a step that writes the NuGetPackageVersion to the job summary and the log, placed before restore/build so it stays legible when a later step fails. Cutting a release then means reading that line off a green main build and tagging with exactly it. * Add release.yml: verify the tag, then publish both packages There was no release workflow at all - dotnet.yml pushes to MyGet on main, and nothing publishes to nuget.org, so every release to date must have been pushed by hand. That is also why the broken tag pattern went unnoticed. Triggered by a published GitHub Release, with workflow_dispatch as a dry run that does everything except the tag check and the push, so the pipeline can be proven without cutting a release. The guard is the point: nbgv computes the version from version.json plus commit height, so the tag name does not set it and a mistyped tag would otherwise ship a package that disagrees with its release. The step compares the two and fails loudly instead. A leading "v" is stripped, matching the v? pattern this PR also fixes. Publishes **both** packages: Dapper.AOT and Dapper.Advisor are both on nuget.org at 1.0.52, and both set GeneratePackageOnBuild for Release, so a Release build produces the pair and the collect step gathers them with the same glob dotnet.yml already uses. They are uploaded as a run artifact before the push, so a failed push does not cost the build. Auth is Trusted Publishing (OIDC) - no long-lived key in the repo. That needs setup outside this file, recorded in the header comment: a GitHub environment named "release", a NUGET_USER secret, and a trusted-publishing policy on nuget.org for *each* of the two packages. No further versionHeightOffset delta: the repo squash-merges, so this lands as one commit on main regardless of how many are on the branch, and -3 still computes 1.1.0. * Drop the MyGet push, and give the README badges release.yml now publishes to nuget.org on a tagged release, so the MyGet push on every main build is both redundant and a second, unversioned place for packages to appear. Removed, along with the Pack and Purge steps that existed only to feed it - packaging is still exercised on every build, because both src projects set GeneratePackageOnBuild for Release, so a broken nuspec still fails CI. That also retires the MYGETAPIKEY secret; nothing references it now. Badges: there were none at all, so this adds rather than updates - build status, and current nuget.org versions for both published packages. Worth having now that a release actually lands on nuget.org by a route anyone can see. * Fix the stale netfx golden #220 left behind The new net48 CI step caught this on its first real outing, which is exactly what it was added for: CommandDefinitionOverloads.output.netfx.txt still claimed "2 skipped silently" and carried no DAP057, because #220 was developed on Linux and only the .output.* goldens can be regenerated there - the .output.netfx.* twins need an actual net48 run. Swept the rest rather than fixing just the one that failed: comparing every .output.txt against its .output.netfx.txt, this is the *only* pair whose diagnostic ids differ, and the only one whose scorecard buckets disagree. The other scorecard differences are legitimate - netfx genuinely has fewer call-sites (15 of 15 vs 17 of 17, and so on), and DateOnly.net6 is gated off netfx entirely. The generated-code goldens are untouched: #220 added diagnostics, not code, and the handled count is 1 of 3 on both sides either way. * Say which ref the computed version belongs to The first real run printed `1.1.4-g90538b49e3` on this PR, which is correct and misleading at once: a PR builds refs/pull/N/merge, whose height includes every branch commit plus the merge, so it is not the number that will ship. Squash-merged onto main the same work computes 1.1.0. Since the whole point of this step is "read this, tag with it", that gap is a live mis-tag waiting to happen. On main the summary now says to tag with exactly that value; anywhere else it says, in the summary itself, that the number is not the one that would ship and to read it off a main run instead. The log line carries the ref either way. release.yml's guard would catch the resulting mismatch, but not hitting it beats being caught by it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The job already runs on
windows-latestand builds net48, so a compile break there would be caught. But the only test steps are net8.0 and net10.0:That gap matters for one specific reason: the
*.output.netfx.*interceptor goldens are compared at test time, not build time. So a netfx golden can be wrong while CI stays green — which is exactly the statemainis in right now. #214, #216 and #220 all touched those files, and none of them could be exercised on Linux; the netfx goldens went in on reasoning rather than on a green run.One more step, same job, same image, same
!~Integrationfilter.This PR's own CI run is the verification — if the netfx goldens from those three PRs are right, it goes green and the gap is closed permanently. If they are wrong, we find out here rather than after shipping 1.1.0, which is the entire point.