Skip to content

Contributing

Experimental Containers Reviewed 2026-10-01 purview-dev/containers Star on GitHub 3 azurite containers csharp docker dotnet integration-testing mysql nats nuget postgresql rabbitmq redis sql-server testcontainers testing windows wsl wsl-containers wslc

Experimental. This project is an experiment: the public API, defaults and packaging can change between prereleases, and there is no production support guarantee.

Contributing

Section titled “Contributing”

Local workflow for the repository: prerequisites, the change loop, and what to check before raising a pull request.

Prerequisites

Section titled “Prerequisites”
  • Windows with WSL Containers for integration tests; see Getting Started.
  • .NET SDK 11 (pinned in global.json as 11.0.100-rc.1.26425.128).
  • The library projects split by framework: src/src/Directory.Build.props sets net10.0 for the backend-neutral abstractions and the service modules. src/src/Wsl/Wsl.csproj is multi-target (net10.0 facade + net10.0-windows10.0.19041.0 implementation) because the WSL Containers projection is Windows-only. src/tests keeps the Windows target (src/Directory.Build.props), which also sets EnableWindowsTargeting=true so the solution builds on the Linux CI agent. Do not remove that property: without it the shared pipeline fails with NETSDK1100. See Consumer Requirements.
  • just for the repository recipes, and dotnet tool restore for the pinned local tools (CSharpier, dotnet-inspect).
  • Bun only for just version and the commit hook tooling; the commit hook runs npx commitlint via lefthook (.config/lefthook.yml).

The change loop

Section titled “The change loop”
  1. Inspect the working tree and locate the implementation, tests, documentation and existing patterns for the change.
  2. Confirm behaviour from code and tests rather than memory or documentation alone.
  3. Make the smallest coherent change; keep public behaviour unless the task explicitly changes it.
  4. Add or update tests for behaviour changes, and update documentation when public behaviour changes.
  5. Run the narrowest meaningful validation first, then broader validation in proportion to risk.
Terminal window
just build                      # fast compile check
just test '/*/*/*/*[Category=Unit]'   # unit tests (no WSLC host needed)
just lint-fix                   # CSharpier format (just lint-check to verify only)
just pack                       # build + pack into ./artifacts
just verify-consumers           # build throwaway consumers against the packed packages
just pipeline-pack-validate     # full local gate: restore, build, lint, test, pack, validate

just scrub resets the repository (bin/obj, clean, forced restore, build-server shutdown) when a stale restore or compiler state is suspected.

Commits

Section titled “Commits”

Commit messages follow Conventional Commits (commitlint.config.mts): a lower-case type from build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test, an optional scope, and a subject under 100 characters with no trailing full stop. The commit-msg lefthook runs npx commitlint --edit and rejects anything else.

Documentation expectations

Section titled “Documentation expectations”

A change is not complete until the affected documentation matches:

  • src/src/<Project>/Sdk/README.md — the package’s own README, shipped inside the .nupkg. Update it whenever a module’s public API, defaults, readiness or endpoints change.
  • docs/wiki — the user-facing wiki aggregated by the purview-dev website. Update the topic page (Consumer Requirements, Architecture, Lifecycle, Networking, Wait Strategies, Modules, Testing, Packaging, Release Flow) and _Sidebar.md when adding a page.
  • purview-build.json — the exhaustive PackValidation.RequiredContent manifest has to keep matching what the packages actually contain; see Packaging.
  • README.md — the repository front page, when the shape of the project changes.

Before you raise a PR

Section titled “Before you raise a PR”
  • Confirm the requested behaviour and scope are satisfied and that only intended files changed.
  • Review public API, package-content and dependency-direction implications.
  • Run just lint-check, the relevant tests, and just pipeline-pack-validate when packaging, dependencies or package assets changed.
  • State exactly what validation ran; if something could not run, say why and what risk remains.
Section titled “Related”