Release pipeline via GitHub Releases + StrongTypes.FsCheck package (#34, #40)

[KaliCZ]

Summary

• Replaces the old "push to main → publish" pipeline with a GitHub Release–driven flow in .github/workflows/build.yml
• Adds the new Kalicz.StrongTypes.FsCheck package — shared FsCheck arbitraries, discovered automatically by the publish step
• Packages ship lockstep at a single version; release notes come from the GitHub Release body

Closes #34. Closes #40.

How a release works

1. Draft a GitHub Release → tag v0.4.0, target main
2. Fill in release notes (start from .github/RELEASE_TEMPLATE.md if helpful)
3. Publish → build.yml runs: build job verifies the commit (tests included), then publish job packs and pushes every publishable nupkg to nuget.org
4. All publishable packages land on nuget.org at 0.4.0

git push origin v0.4.0 alone does nothing. Only publishing a GitHub Release triggers publish.

Workflow structure

Single build.yml with two jobs:

• build — runs on push to main, PR to main, and release:published. Restore, build, test, upload test logs.
• publish — runs on release:published only, needs: build. Parses the tag, passes version + release notes to dotnet build, pushes the resulting nupkgs.

needs: build guarantees tests pass on the release commit before any package leaves the box.

Safety layers stacking

1. Tag ruleset (set up separately via Settings): only admins can create v* tags; tag creation requires a green build check from build.yml on the tagged commit.
2. Environment restriction (set up on the Nuget.org environment): allowed refs restricted to v* tags.
3. Workflow gate: publish job conditional on github.event.release.target_commitish == 'main' — rejects Releases drafted against any branch other than main.
4. Fresh re-test: the build job runs on the release event itself before publish starts.
5. Duplicate-push protection: dotnet nuget push (no --skip-duplicate) fails loudly if a version was already shipped.

Publish is convention-based, not hardcoded

The pack step is a single dotnet build StrongTypes.slnx with -p:Version, -p:PackageReleaseNotes, and -p:PackageOutputPath. Publishable projects have <PackageId> + <GeneratePackageOnBuild>true</GeneratePackageOnBuild>; non-publishable ones set <IsPackable>false</IsPackable>. Future publishable packages join the release stream automatically just by following the convention.

Today that covers three packages: Kalicz.StrongTypes, Kalicz.StrongTypes.EfCore, Kalicz.StrongTypes.FsCheck.

Version-matching across packages

EfCore's and FsCheck's <ProjectReference> to core picks up the cascading -p:Version MSBuild property, so when CI builds them at 0.4.0, the generated nuspec writes <dependency id="Kalicz.StrongTypes" version="0.4.0" /> automatically. Verified locally.

New FsCheck package

Moves the shared arbitraries from src/StrongTypes.Tests/Generators.cs into src/StrongTypes.FsCheck/ with namespace StrongTypes.FsCheck. Consumers register everything with a single attribute:

using StrongTypes.FsCheck;

[Properties(Arbitrary = new[] { typeof(Generators) })]
public class MyTests { ... }

Runtime dep is FsCheck 3.3.2 (no xunit-specific bits). Internal test project picks up the type via a new GlobalUsings.cs so the existing 11 test files keep referencing Generators unqualified.

csproj changes (Version/Notes)

Removed from the publishable csprojs:

• <Version>, <AssemblyVersion>, <FileVersion> (now -p:Version from the tag)
• <PackageReleaseNotes> (now -p:PackageReleaseNotes from the Release body)

Each publishable csproj keeps <Version>0.0.0-dev</Version> as a local-build placeholder.

Test plan

• Merge PR
• Configure tag ruleset: target v*, restrict creations/updates/deletions (admin bypass), require status check build
• Configure Nuget.org environment: add allowed deployment tag pattern v*
• Cut a pre-release (v0.3.1-test.1) to validate end-to-end — all three packages should land on nuget.org at that version
• Confirm routine push to main does not trigger publish
• Once green, cut the real v0.4.0

🤖 Generated with Claude Code