Helpers for interacting with Helm CLI.
Get Started
$ dotnet add package ModularPipelines.HelmReadme
ModularPipelines
Write CI/CD pipelines in C#. Debug them locally. Ship with confidence.
Helpers for interacting with Helm CLI.
$ dotnet add package ModularPipelines.HelmWrite CI/CD pipelines in C#. Debug them locally. Ship with confidence.
You know the drill. You write some YAML, push it, wait for CI to start, watch it fail on a typo, fix it, push again, wait again. Repeat until you lose the will to live.
YAML pipelines are:
ModularPipelines lets you write your CI/CD pipelines as regular C# code. That means:
Set a breakpoint. Step through your pipeline. Fix it before you push.
[DependsOn<BuildModule>]
[DependsOn<TestModule>]
public class PublishModule : Module<CommandResult>
{
protected override async Task<CommandResult?> ExecuteAsync(IPipelineContext context, CancellationToken cancellationToken)
{
// This is real C#. Set a breakpoint. Inspect variables. Debug locally.
return await context.DotNet().Publish(new DotNetPublishOptions
{
Project = "src/MyApp/MyApp.csproj",
Configuration = Configuration.Release,
Output = "publish/"
}, cancellationToken);
}
}Intellisense, refactoring, compile-time errors. Your pipeline code gets the same treatment as your application code. Rename a module? Your IDE updates all the references. Typo in an option? Red squiggle before you even save.
Test your entire pipeline on your machine before pushing. No more "let me push and see if it works" commits. Debug failures in your IDE instead of reading logs from a build agent.
Modules declare their dependencies with attributes. ModularPipelines figures out what can run in parallel and maximizes throughput. No more manually orchestrating parallel jobs.
Your pipeline logic lives in C#, not in vendor-specific YAML. Moving from GitHub Actions to Azure Pipelines to TeamCity? Change one line - your modules stay the same.
Inject services, configuration, and secrets the same way you do in ASP.NET Core. Mock dependencies for testing. No more environment variable gymnastics.
Secrets are automatically obfuscated in logs. No more accidentally exposing API keys in build output.
Modules return strongly-typed results that other modules can consume. No shared mutable state - just clean data flow.
// BuildModule returns version info
public class BuildModule : Module<BuildInfo>
{
protected override async Task<BuildInfo?> ExecuteAsync(IModuleContext context, CancellationToken cancellationToken)
{
await context.DotNet().Build(new DotNetBuildOptions { Project = "MyApp.csproj" }, cancellationToken);
return new BuildInfo { Version = "1.0.0", OutputPath = "bin/Release" };
}
}
// PublishModule retrieves and uses it
[DependsOn<BuildModule>]
public class PublishModule : Module
{
protected override async Task ExecuteAsync(IModuleContext context, CancellationToken cancellationToken)
{
var buildResult = await GetModule<BuildModule>();
var outputPath = buildResult.Value!.OutputPath; // Strongly-typed, compile-time checked
// Publish using the build output...
}
}Built-in Roslyn analyzers catch common mistakes before you even run:
[DependsOn] when calling GetModule<T>()await module resultsConsole.Write instead of the logging systemdotnet new console -n MyPipeline
cd MyPipeline
dotnet add package ModularPipelines// Program.cs
await PipelineHostBuilder.Create()
.AddModule<BuildModule>()
.AddModule<TestModule>()
.AddModule<PublishModule>()
.ExecutePipelineAsync();// BuildModule.cs
public class BuildModule : Module<CommandResult>
{
protected override async Task<CommandResult?> ExecuteAsync(IPipelineContext context, CancellationToken cancellationToken)
{
return await context.DotNet().Build(new DotNetBuildOptions
{
Project = "MySolution.sln",
Configuration = Configuration.Release
}, cancellationToken);
}
}// TestModule.cs
[DependsOn<BuildModule>]
public class TestModule : Module<CommandResult>
{
protected override async Task<CommandResult?> ExecuteAsync(IPipelineContext context, CancellationToken cancellationToken)
{
return await context.DotNet().Test(new DotNetTestOptions
{
Project = "MySolution.sln",
Configuration = Configuration.Release
}, cancellationToken);
}
}Run it:
dotnet runThat's it. No YAML. No waiting for CI. Just dotnet run and watch your pipeline execute.
See exactly what's happening as your pipeline runs:
Get a clear summary when your pipeline completes:
ModularPipelines has strongly-typed wrappers for the tools you already use:
| Package | Description | Version |
|---|---|---|
| ModularPipelines | Write your pipelines in C#! | |
| ModularPipelines.AmazonWebServices | Helpers for interacting with Amazon Web Services. |  |
| ModularPipelines.Azure | Helpers for interacting with Azure. |  |
| ModularPipelines.Azure.Pipelines | Helpers for interacting with Azure Pipeline agents. |  |
| ModularPipelines.Chocolatey | Helpers for interacting with the Chocolatey CLI. |  |
| ModularPipelines.Cmd | Helpers for interacting with the Windows cmd process. |  |
| ModularPipelines.Docker | Helpers for interacting with the Docker CLI. |  |
| ModularPipelines.DotNet | Helpers for interacting with dotnet CLI. |  |
| ModularPipelines.Email | Helpers for sending emails. |  |
| ModularPipelines.Ftp | Helpers for downloading and uploading via FTP. |  |
| ModularPipelines.Yarn | Helpers for interacting with Yarn CLI. |  |
| ModularPipelines.Node | Helpers for interacting with node / npm CLI. |  |
| ModularPipelines.Git | Helpers for interacting with git. |  |
| ModularPipelines.GitHub | Helpers for interacting with GitHub Actions build agents. |  |
| ModularPipelines.Google | Helpers for interacting with the Google gcloud CLI. |  |
| ModularPipelines.Helm | Helpers for interacting with Helm CLI. |  |
| ModularPipelines.Kubernetes | Helpers for interacting with kubectl CLI. |  |
| ModularPipelines.MicrosoftTeams | Helpers for sending Microsoft Teams cards. |  |
| ModularPipelines.Slack | Helpers for sending Slack cards. |  |
| ModularPipelines.TeamCity | Helpers for interacting with TeamCity build agents. |  |
| ModularPipelines.Terraform | Helpers for interacting with Terraform CLI. |  |
| ModularPipelines.WinGet | Helpers for interacting with the Windows Package Manager. |  |
| ModularPipelines | Cake | Nuke | |
|---|---|---|---|
| Language | Real C# | C# DSL (scripted) | Real C# |
| Parallelization | Automatic based on dependencies | Manual | Manual |
| Architecture | Separate module classes (SRP) | Single build script | Single build class |
| Dependency Injection | Full Microsoft.Extensions.DI | Limited | Built-in but different |
| Setup | dotnet run | Requires bootstrapper | Requires global tool |
| Module Communication | Strongly-typed return values | Shared state | Parameters |
ModularPipelines takes a different approach: each unit of work is a self-contained module class. This keeps code organized, makes merge conflicts rare, and lets you test modules in isolation.
DependsOnIf<T>() for dynamic dependency graphsWhile I aim to maintain stability, minor versions may include breaking changes. These will always be documented in release notes.