Top 4 C# Orchestration Projects

Cake

3 3,585 9.1 C#

:cake: Cake (C# Make) is a cross platform build automation system.

Project mention: Unpopular opinion: CI/CD engines are an awful idea | reddit.com/r/devops | 2023-02-04

This is why 90-99% of our builds are done with Cake. It isolates all of it and you can run the build locally if you want.
NUKE

15 1,905 8.3 C#

🏗 The AKEless Build System for C#/.NET (by nuke-build)

Project mention: ModularPipelines - Strong-Typed, Parallel, C# Pipelines - Would appreciate feedback and thoughts | reddit.com/r/csharp | 2023-05-29

Is it similar to Nuke?
ONLYOFFICE

www.onlyoffice.com
sponsored

ONLYOFFICE Docs — document collaboration in your environment. Powerful document editing and collaboration in your app or environment. Ultimate security, API and 30+ ready connectors, SaaS or on-premises
FlubuCore

0 853 5.0 C#

A cross platform build and deployment automation system for building projects and executing deployment scripts using C# code.
BuildXL

1 824 9.0 C#

Microsoft Build Accelerator

Project mention: Using Landlock to Sandbox GNU Make | news.ycombinator.com | 2022-08-07

> With regards to chroot, I stand corrected. I knew it was a tree of symlinks, but I thought it was also more than that because symlinks alone don't seem like a sandbox. Honestly, Cosmopolitan's system appears to be more of a sandbox than that.
To be totally clear: the tree of symlinks thing is a fallback, used only when lacking platform support or when sandboxing is explicitly turned off [0]. On Linux, the normal sandboxing strategy is to use namespaces, like most container runtimes. On Mac it apparently uses sandbox-exec (some opaque Apple tool), as was mentioned above. Chroot, being both non-POSIX, requiring root access on many systems, and not providing the necessary facilities is not really a great fit -- which I assume is why it's not used.
There was experimental Windows sandbox support at one point [1] based on how MS does it for BuildXL (their own build tool for giant monorepos) [2]. Unfortunately it doesn't seem to be maintained, and under the hood it's kinda ugly -- it actively rewrites code in-memory to intercept calls to the Win32 APIs [3], which was apparently the cleanest/best way MS could come up with. However, from Bazel's POV it works in a roughly similar way -- you spawn subprocesses under a supervisor, which is in charge of spinning up whatever the target process is with restrictions on time/memory usage/file access.
On the "sandbox in the interpreter" thing: what kind of checks are you envisioning? It seems like putting checks at that level would end up leaving a lot out -- the goal of any build system is to eventually spawn an arbitrary process (Python, gcc, javac, some shell script, etc.) and so even with extensive checks in starlark you'd end up with accidental sandbox breaks all over the place. For pure starlark rules you could e.g. check that there are no inputs from /usr, but even then if gcc does it implicitly, you're SOL. Or am I thinking of the wrong kind of checks?
[0] https://bazel.build/docs/sandboxing#sandboxing-strategies
[1] https://github.com/bazelbuild/bazel/issues/5136#issuecomment...
[2] https://github.com/microsoft/BuildXL/blob/master/Documentati...
[3] https://github.com/microsoft/Detours/wiki

NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020). The latest post mention was on 2023-05-29.