CI

On this page

1. Jobs
2. When jobs run
3. Releases
4. Project requirements
5. Building installers locally

One pipeline, .gitlab-ci.yml at the repository root, builds every component. Components reference each other as ordinary ProjectReferences, so each job compiles what it depends on from source. Restore uses only the public feeds in nuget.config — nuget.org and npgsql-vnext — so no NuGet credentials are involved anywhere.

Jobs

Job	Runs on	Does
build:agent	Linux, .NET 10 SDK	Builds ProvCollector.Agent.slnx
build:backend	Linux, .NET 10 SDK	Builds ProvCollector.Backend.slnx
build:analysis	Linux, .NET 10 SDK + Node 22	Builds ProvCollector.Analysis.slnx
build:management	Linux, .NET 10 SDK + Node 22	Builds ProvCollector.Management.slnx
build:installers:windows	Windows runner	Builds the Agent and Updater MSIs
upload:installers:windows	Tags	Pushes the MSIs to the GitLab generic package registry
release	Tags	Creates the GitLab release, linking those MSIs
deploy:docs:cloudflare	Default branch	Publishes the dashboard API reference via wrangler

ProvCollector.Agent.Windows targets net10.0-windows. It is a plain worker service with no WPF/WinForms dependency, so build:agent cross-builds it on Linux by passing -p:EnableWindowsTargeting=true to both restore and build.

The Analysis and Management jobs install Node because ProvCollector.Visualizer and ProvCollector.AgentDashboard run npm install and npm run build from an MSBuild target, and Tailwind 4 needs Node 20 or later.

The build jobs compile the test projects, so a test that no longer compiles fails the pipeline. Running the tests needs Postgres and Garnet service containers and is not wired up yet.

When jobs run

On branches and merge requests, each build job runs only when something it depends on changed: its own component directory, a component it references, nuget.config, or the pipeline file. Everything references ProvCollector.Common, so a change there rebuilds every component; a change under ProvCollector.Backend also rebuilds Analysis, whose tests use the writer.

Tags and the default branch always build everything.

If a merge request pipeline is missing a job you expected, check whether the change touched that job’s paths before suspecting the runner.

Releases

Pushing a tag builds the MSIs with the tag as their version — a leading v is stripped, so v2.3.4 produces ProductVersion 2.3.4 — uploads them to the generic package registry under windows-installers/<tag>/, and creates a GitLab release linking them.

Project requirements

The pipeline needs, on the GitLab project:

• a runner carrying the tag in $WINDOWS_RUNNER_TAG (default windows) for build:installers:windows;
• wrangler’s Cloudflare credentials as CI/CD variables, normally CLOUDFLARE_API_TOKEN, for deploy:docs:cloudflare.

Building installers locally

ProvCollector.Management/Build-Installers.ps1 builds a configured agent installer for either platform, injecting Kafka settings and a CA certificate into the platform’s default.yaml before packaging. Windows produces MSIs from the WiX v6 projects; Linux produces self-extracting Rust setup binaries.

Uploaded packages are served to updaters through /api/v1/updates, with PackageManagementService publishing a SHA-256 digest per package. The updater verifies that digest before installing, and refuses to install a package for which no digest is published.