Prerequisites
- Docker with
buildx - BuildCharts installed locally or globally
- A repository root that contains a
.slnor.slnxfile if you want to usebuildcharts init
Scaffold a repository
Runbuildcharts init from the repository root.
- Creates
build.yml - Creates
charts/buildcharts/Chart.yaml - Creates
.github/workflows/buildcharts.ymlwhen the Git remote points to GitHub
init currently supports .NET repositories only.
Use the built-in .NET charts
BuildCharts ships with first-class .NET charts for common stage types. These are a practical starting point when you want working defaults before you introduce your own chart ecosystem. The built-in .NET chart set is documented here: The shipped Dockerfiles cover the common .NET workflows:buildrunsdotnet buildtestrunsdotnet testand prepares test artifactsnugetrunsdotnet packand prepares package outputpublishrunsdotnet publishdockerpublishes the app and assembles the runtime image
build.yml.
Dependency chart
build.yml to the built-in .NET charts.
Review the generated metadata
This shape matches the shipped samples:build target.
Parallelization: multiple targets vs dotnet test
If you prefer, you can also put build and test directly on the solution target. This works well for .NET because dotnet build and dotnet test can run directly against a solution, so the solution can act as the shared source for both stages:
dotnet test, which then delegates to the test framework and runner, such as xUnit, NUnit, or MSTest.
The tradeoff is execution strategy:
- solution-level
testkeeps the config simpler and matches normal .NET workflows - separate test targets can let Docker Bake parallelize more work across targets
- separate targets may also benefit differently from Docker layer caching
From .NET 9, the same test project can run across different target frameworks in parallel through MSBuild.
Create a lock file
buildcharts generate works without charts/buildcharts/Chart.lock, but buildcharts update gives you pinned chart digests and lets generate detect drift.