Make parameters first-class in the CLI and deployment pipeline
- 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
Assessment
This issue has not been assessed yet.