diff --git a/src/frontend/src/content/docs/deployment/azure/container-apps.mdx b/src/frontend/src/content/docs/deployment/azure/container-apps.mdx index ab5dc36d9..7b5e26900 100644 --- a/src/frontend/src/content/docs/deployment/azure/container-apps.mdx +++ b/src/frontend/src/content/docs/deployment/azure/container-apps.mdx @@ -325,14 +325,14 @@ After deployment, use the dashboard URL in the CLI output, the Azure portal, or ## Clean up resources -To remove deployed resources, delete the resource group: +To tear down deployed resources, use `aspire destroy`. The command discovers the deployment, lists the Azure resources it will remove, and prompts for confirmation before deleting the resource group: -```bash title="Delete resource group" -az group delete --name +```bash title="Aspire CLI - Destroy the deployed environment" +aspire destroy ``` :::danger -This command deletes all resources in the resource group, including any resources not created by the Aspire CLI. +`aspire destroy` deletes the entire resource group, including any resources that weren't created by the Aspire CLI. Pass `--yes` only in automated or CI scenarios where you've already validated what will be removed. This action cannot be undone. ::: ## See also diff --git a/src/frontend/src/content/docs/deployment/docker-compose.mdx b/src/frontend/src/content/docs/deployment/docker-compose.mdx index ca87dd285..c57210325 100644 --- a/src/frontend/src/content/docs/deployment/docker-compose.mdx +++ b/src/frontend/src/content/docs/deployment/docker-compose.mdx @@ -149,13 +149,19 @@ Aspire provides a progressive deployment workflow for Docker Compose, allowing y ### Clean up deployment -To stop and remove a running Docker Compose deployment, use the `aspire do docker-compose-down-{resource-name}` command: +To stop and remove a running Docker Compose deployment, use the `aspire destroy` command: ```bash title="Terminal" -aspire do docker-compose-down-env +aspire destroy ``` -This command stops and removes all containers, networks, and volumes created by the Docker Compose deployment. +The command shows the resources that will be removed and prompts for confirmation. Once confirmed, it stops and removes all containers, networks, and volumes created by the Docker Compose deployment. + + ## Multi-environment deployments diff --git a/src/frontend/src/content/docs/deployment/pipelines.mdx b/src/frontend/src/content/docs/deployment/pipelines.mdx index 8d6c2559e..9fae32cb7 100644 --- a/src/frontend/src/content/docs/deployment/pipelines.mdx +++ b/src/frontend/src/content/docs/deployment/pipelines.mdx @@ -434,24 +434,13 @@ For complete command reference, see [aspire do command](/reference/cli/commands/ ### Discovering available steps -Before executing pipeline steps, you can discover what steps are available using the `diagnostics` step: +Before executing pipeline steps, you can discover what steps would run for a given command using the `--list-steps` flag. Every pipeline command (`aspire deploy`, `aspire publish`, `aspire destroy`, and `aspire do`) accepts it: ```bash title="Aspire CLI — Discover pipeline steps" -aspire do diagnostics +aspire deploy --list-steps ``` -This command displays: -- All available steps and their dependencies. -- Execution order with parallelization indicators. -- Step dependencies and target resources. -- Configuration issues like orphaned steps or circular dependencies. - -The output includes several sections: - -- **Execution order**: A numbered list showing the order in which steps would execute -- **Detailed step analysis**: Each step's dependencies, associated resources, tags, and descriptions (✓ = dependency exists, ? = dependency missing) -- **Potential issues**: Identifies problems like orphaned steps or circular dependencies -- **Execution simulation**: "What if" analysis showing what steps would run for each possible target step, with concurrency indicators for steps that can run in parallel +This lists the pipeline steps that would be executed by the chosen command, in execution order, without running them. Pair `--list-steps` with the command you intend to run (for example, `aspire publish --list-steps` or `aspire do build --list-steps`) to see exactly which steps a given invocation would trigger. ## Custom pipeline steps @@ -669,7 +658,7 @@ Follow these steps to replace your Aspire 9.x publishing code with Aspire 13.x p 1. **Identify publishing callbacks** in your code that use `WithPublishingCallback`. 2. **Convert callbacks to pipeline steps** using `WithPipelineStepFactory` or `builder.Pipeline.AddStep`. 3. **Update dependencies** with parameters or properties. When using `builder.Pipeline.AddStep`, configure dependencies with the `dependsOn` / `requiredBy` parameters. When creating `PipelineStep` instances directly, use the `DependsOn` and `RequiredBySteps` properties. -4. **Test the migration** using `aspire do diagnostics` and `aspire do deploy`. +4. **Test the migration** using `aspire deploy --list-steps` and `aspire deploy`. @@ -793,7 +782,7 @@ builder.Pipeline.AddStep("smoke-tests", async (context) => The pipeline system provides several advantages over publishing callbacks: -- **Better visibility**: Use `aspire do diagnostics` to see all steps and their dependencies. +- **Better visibility**: Use `aspire deploy --list-steps` to see all steps that would run for a deploy and the order they'd run in. - **Selective execution**: Run specific steps with `aspire do `. - **Parallel execution**: Independent steps run concurrently automatically. - **Clearer dependencies**: Explicit dependency declaration with `DependsOn` and `RequiredBySteps`. @@ -801,5 +790,5 @@ The pipeline system provides several advantages over publishing callbacks: - **Reusability**: Steps can be reused across different deployment scenarios. diff --git a/src/frontend/src/content/docs/get-started/deploy-first-app.mdx b/src/frontend/src/content/docs/get-started/deploy-first-app.mdx index 2aeb18379..a26cb68c8 100644 --- a/src/frontend/src/content/docs/get-started/deploy-first-app.mdx +++ b/src/frontend/src/content/docs/get-started/deploy-first-app.mdx @@ -297,7 +297,7 @@ In the AppHost, chain a call to the appropriate environment API method to config @@ -368,7 +368,7 @@ In the AppHost, chain a call to the appropriate environment API method to config @@ -1135,22 +1135,18 @@ To verify that your application is running as expected after deployment, follow After deploying your application, it's important to clean up resources to avoid incurring unnecessary costs or consuming local system resources. - - - To clean up resources after deploying with Docker Compose, you can stop and remove the running containers using the following command: +Use `aspire destroy` to tear down the deployed environment. The command discovers the deployment, shows what will be removed, and prompts for confirmation before continuing. - ```bash title="Aspire CLI - Stop and remove containers" - aspire do docker-compose-down-env - ``` - - - To clean up resources after deploying to Azure, you can use the Azure CLI to delete the resource group that contains your application. This will remove all resources within the resource group. +```bash title="Aspire CLI - Destroy the deployed environment" +aspire destroy +``` - ```bash title="Azure CLI - Delete resource group" - az group delete --name --yes --no-wait - ``` - - + For a deep-dive into the related foundational concepts, see [Pipelines and app topology](/deployment/pipelines/). @@ -1163,23 +1159,18 @@ You've just built your first Aspire app and deployed it to production. Now you m After deploying your application, it's important to clean up resources to avoid incurring unnecessary costs or consuming local system resources. - - - To clean up resources after deploying with Docker Compose, you can stop and remove the running containers using the following command: - - ```bash title="Aspire CLI - Stop and remove containers" - aspire do docker-compose-down-env - ``` - - - To clean up resources after deploying to Azure, you can use the Azure CLI to delete the resource group that contains your application. This will remove all resources within the resource group. +Use `aspire destroy` to tear down the deployed environment. The command discovers the deployment, shows what will be removed, and prompts for confirmation before continuing. - ```bash title="Azure CLI - Delete resource group" - az group delete --name --yes --no-wait - ``` - +```bash title="Aspire CLI - Destroy the deployed environment" +aspire destroy +``` - + For a deep-dive into the related foundational concepts, see [Pipelines and app topology](/deployment/pipelines/). diff --git a/src/frontend/src/content/docs/reference/cli/commands/aspire-do.mdx b/src/frontend/src/content/docs/reference/cli/commands/aspire-do.mdx index 498d563f1..1ea288f91 100644 --- a/src/frontend/src/content/docs/reference/cli/commands/aspire-do.mdx +++ b/src/frontend/src/content/docs/reference/cli/commands/aspire-do.mdx @@ -89,16 +89,17 @@ The following options are available: ## Discovering available steps -Before executing a pipeline step, you can discover what steps are available in your application's pipeline and understand their dependencies using the `diagnostics` step. +Before executing a pipeline step, you can discover which steps would run for a given command and understand their dependencies using the `--list-steps` flag. ### Understanding pipeline structure -The `aspire do diagnostics` command provides comprehensive information about your pipeline, including: +Running any pipeline command with `--list-steps` lists the steps that would execute, in order, without actually running them: -- All available steps and their dependencies -- Execution order with parallelization indicators -- Step dependencies and target resources -- Configuration issues like orphaned steps or circular dependencies +```bash title="Aspire CLI" +aspire do --list-steps +``` + +`--list-steps` is supported by every pipeline command (`aspire deploy`, `aspire publish`, `aspire destroy`, and `aspire do`), so you can scope the listing to a specific operation — for example, `aspire deploy --list-steps` shows only the steps required to deploy. This is particularly useful after installing a deployment package or when you want to understand which steps will execute for a given command. @@ -120,10 +121,10 @@ The following examples demonstrate common pipeline operations: - Examine the pipeline structure and available steps: ```bash title="Aspire CLI" - aspire do diagnostics + aspire do --list-steps ``` - This displays all steps in your pipeline, their dependencies, and execution order. Use this to understand what steps are available and how they relate to each other. + This lists the pipeline steps that would run, in execution order, without running them. Pair `--list-steps` with the command you intend to run (for example, `aspire deploy --list-steps`) to see exactly which steps a given invocation would trigger. - Build container images for your application: diff --git a/src/frontend/src/content/docs/whats-new/aspire-13.mdx b/src/frontend/src/content/docs/whats-new/aspire-13.mdx index 932a06911..68326f2d1 100644 --- a/src/frontend/src/content/docs/whats-new/aspire-13.mdx +++ b/src/frontend/src/content/docs/whats-new/aspire-13.mdx @@ -1304,7 +1304,7 @@ This enables incremental deployments, debugging specific steps, and CI/CD pipeli **Pipeline diagnostics:** -Use `aspire do diagnostics` to understand your pipeline graph, view execution order with parallelization indicators, see step dependencies and resources, simulate "what if" scenarios, and detect configuration issues like orphaned steps or circular dependencies. +Use the `--list-steps` flag (available on `aspire deploy`, `aspire publish`, `aspire destroy`, and `aspire do`) to inspect the pipeline that would run for a given command — including step order, dependencies, and the resources each step targets — without actually executing it. **Benefits:**