Repository navigation
Description
We are establishing a regression testing pipeline that builds real-world OSS F# projects against every pull request to the F# compiler. We're looking for maintainers interested in participating in this pilot program.
Why Participate?
By contributing your project to this initiative, you gain an automated safeguard against compiler regressions. Your codebase will be compiled against proposed compiler changes before they are merged, meaning breaking changes affecting your project will be caught at the source rather than after release.
What We Need
We are particularly interested in projects that make extensive use of F# language features that are not necessarily exercised by the compiler itself:
- Deeply nested Computation expressions and custom builders, including resumable code
- Type providers - authoring as well as consumption
- Pushing Statically Resolved Type Parameters (SRTPs) to its limits
- Quotations and metaprogramming
- Queries
- Interfaces with static abstract methods (IWSAMs) consumption
- ...
Requirements
This is a pilot program, and we ask that participating projects meet the following criteria:
- Stable build process — The project should build reliably with a single command (e.g.,
build.cmd,build.sh, ordotnet build). Flaky builds create noise and reduce the signal we're looking for. - Reproducible state — We pin to a specific commit SHA, so the build must succeed consistently at that point.
- Binary log support — Ideally, your build command should produce MSBuild binary logs (
.binlogfiles). This helps us diagnose issues efficiently when something fails. You can enable this by passing-blto your build, e.g.,dotnet build -bl:build.binlog. - Permissive for CI usage — The project's license should allow compilation in our public CI environment.
A Note on Patience
Depending on your project's setup, integrating it into our infrastructure may require some adjustments on our side. We are happy to work through any issues together — please don't hesitate to ask questions or flag problems in your PR. This is a learning process for us as well.
How to Get Involved
Submit a pull request to dotnet/fsharp that adds your project to the test matrix in azure-pipelines-PR.yml.
Locate the regression test section at the end of the file and add an entry to testMatrix:
- template: /eng/templates/regression-test-jobs. yml
parameters:
testMatrix:
# Existing entry
- repo: fsprojects/FSharpPlus
commit: f614035b75922aba41ed6a36c2fc986a2171d2b8
buildScript: build. cmd
displayName: FSharpPlus_Windows
# Add your project here
- repo: your-org/your-project
commit: abc123def456789... # Full commit SHA
buildScript: build. cmd # Or build.sh, dotnet build, etc.
displayName: YourProject_WindowsEach entry requires:
- repo — GitHub repository in
owner/nameformat - commit — Full commit SHA (ensures reproducible builds)
- buildScript — Command to build the project
- displayName — Identifier for the CI job (use underscores, no spaces)
If your project needs to run on Linux, add a separate entry with useVmImage:
- repo: your-org/your-project
commit: abc123def456789...
buildScript: build.sh
displayName: YourProject_Linux
useVmImage: ubuntu-latestThis is a beta effort, and we welcome feedback on the process as we refine it.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNew
Activity
krauthaufen commentedon Dec 11, 2025
Hey, we could certainly add some of aardvark's components that test various corner-cases of the compiler (using C# libs with thousands of extension methods, srtp at its finest, CE builders to the moon, etc.)
However they are embedded in larger solutions, sometimes also with C# projects. Would that be a problem?
T-Gro commentedon Dec 11, 2025
What is the total build time?
It will run on a separate machine, so as long as it does not start the dominate overall CI time, it is fine.
Heavy C# interop is welcome, it is one of the parts with low dogfooding I forgot to list (especially when it comes no non-BCL and low-level usage)
krauthaufen commentedon Dec 11, 2025
I can put together a list of good candidates. Just so i know: what would you consider too long build time?
We can maybe also create a special repo with copies of the relevant libs that just builds these.
T-Gro commentedon Dec 12, 2025
Anything below 20 minutes is fine - I hope copies are not needed.
We can also have multiple entries (e.g. cloning the same repo, but running a different script ).
T-Gro commentedon Feb 10, 2026
Adding some more revealed legitimate .NET 10 regressions.
I would love if we can leverage this mechanism even more to prevent future bugs.
#19260