CI only for affected projects – Blazor architecture at scale (W11, lesson 6)

What you learn in this lesson

explain why a path filter alone is not enough in a solution with references between projects

read the dependency graph from the project files and determine from a git diff the affected projects, including all that depend on them

write a read-only PowerShell script and secure it with a test of its own that can also turn red

build and test only the affected projects and say when shared files trigger everything

name the limits of the approach and place Nx affected as a comparison

The Kladde now has eight projects under src and two test projects. Whoever changes a sentence in docs still has everything built and tested, and whoever touches only Kladde.Tenders waits for the tests of Booking. With ten projects that is annoying; with fifty it is the reason pipelines take twenty minutes and nobody waits for them anymore. This lesson writes a small script that determines from a git diff the projects a change affects, and lets a pipeline build on that: build only these, run only their tests.

Where the Kladde stands

The lesson presupposes W11.2: Kladde.slnx with the modules Kladde.Contacts, Kladde.Booking, Kladde.Tenders (each with .Contracts), Kladde.SharedKernel and the host Kladde.Web, plus tests/Kladde.Architecture.Tests and, new, tests/Kladde.Booking.Tests with a test for the booking. The script lives under scripts/Get-AffectedProjects.ps1, its test beside it. Keep your names and carry the steps over. Kladde.UI from W8 and the consumers from 0301 are not part of this lesson's throwaway solution; through their project references they hang in the graph just the same.

What you learn in this lesson

Where the Kladde stands

This lesson belongs to course W11