microsoft / microsoft/aspire

Make parameters first-class in the CLI and deployment pipeline

Open
#16,091 0 comments 0 reactions 0 assignees View on GitHub
area-cli area-deployment
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 15h
Merged PRs (30d)
196

Description

## Problem

Parameters are central to deployment — they control infrastructure config, secrets, resource names, and application settings. But today they feel bolted on rather than first-class. The CLI syntax for passing them is obscure, there's no clear model for how they flow through the pipeline, and the pipeline steps don't have a consistent way to declare, consume, or validate them.

## Current State

Passing parameter values requires leaking .NET `IConfiguration` internals:

```bash
# What users have to type today
aspire deploy -- --parameters:db-password mysecret
aspire do build -- --parameters:location westus2
```

The `--` separator tells System.CommandLine to stop parsing, and `--parameters:` is .NET configuration provider syntax. Users have to understand both to pass a simple value.

## Expected Experience

### CLI syntax
Parameters should be a first-class CLI argument:

```bash
aspire deploy --set db-password=mysecret --set location=westus2
aspire deploy -p db-password=mysecret
```

### Pipeline integration
- Pipeline steps should be able to **declare** what parameters they need (name, type, description, required/optional, default)
- The CLI should **collect** all declared parameters upfront, not discover them mid-pipeline
- Parameters should **flow** through the pipeline with clear provenance (CLI arg, env var, saved state, prompted)
- Non-interactive mode should **fail fast** with a clear message listing all missing parameters

### Discoverability
- `aspire deploy --help` should show available parameters
- `aspire deploy --list-inputs` should enumerate all required inputs in a machine-readable format
- The prompted UX should show where each parameter comes from and what it's for

## Why This Matters

- **Discoverability** — Users shouldn't need to read source code to know what inputs are needed
- **CI/CD** — Pipeline YAML should be clean: `--set key=value` not `-- --parameters:key value`
- **Consistency** — Other tools (Helm, Terraform, Docker) treat parameters as first-class
- **Agents** — AI coding agents can't easily discover or use the `-- --parameters:` syntax
- **Reliability** — Mid-pipeline parameter discovery leads to failures deep into a deployment

Parent issue: #16090

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.