Triage for dotnet/aspire#9807 by JamesNK - Prompt for values #1139
Description
Triage for dotnet/aspire#9807.
Repo filter: area-dashboard issues.
MihuBot version: c1f103.
Ping MihaZupan for any issues.
dotnet/aspire#9807: Prompt for values by JamesNK
[Tool] Searching for prompt for values, user input at runtime, ask user for value, ValuePromptService, PromptedValue, runtime configuration, dashboard prompt, command line prompt, interactive input (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/aspire)
[Tool] Found 86 issues, 46 comments, 86 returned results (14930 ms)
Here are the most relevant related issues and discussions for issue #9807, "Prompt for values" by JamesNK:
1. Issue #1478 (December 2023) - Introduce prompting behavior to inputs for Aspire manifests
- Summary: This issue discusses adding prompting behavior for resource inputs in Aspire manifests. If a resource input lacks a default value, the deployment tool should prompt the user for a value, possibly persisting it for future runs. The issue also suggests a
promptfield for customizing the prompt text and hints at future support for pick lists and validation. - Key Comments:
- The feature should work for any resource, not just secrets.
- There is interest in supporting shared secrets and app-wide parameters.
- The discussion includes how this would work in local development and CI/CD scenarios.
2. Issue #8915 (April 2025) - Add prompting for parameters in aspire run, aspire publish and aspire deploy
- Summary: Proposes interactive prompting for parameters not supplied to Aspire CLI commands. The idea is to have the CLI communicate with the apphost to prompt for missing parameters, initially supporting simple string prompts and later expanding to richer metadata (e.g., options, validation).
- No comments, but the description aligns closely with the goals of #9807.
3. PR #8520 (April 2025) - Interactive prompting for aspire new
- Summary: Implements interactive prompting for the
aspire newcommand, allowing users to supply values for template parameters interactively. The technical notes discuss why pick-lists were not used for some options and how the CLI is expected to drive template adoption. - Key Comment: For execution environments, there will always be a directory, which is relevant for prompting for output paths.
4. PR #9558 (May 2025) - Prompting for additional template args
- Summary: Enhances the
aspire newcommand to prompt for extra template options based on the selected template, furthering the interactive prompting experience.
5. Issue #9541 (May 2025) - Initial spike of CLI prompting via VSCode extension
- Summary: Explores how the Aspire CLI can delegate prompting to the VSCode extension when running in that environment, by forwarding prompt requests to the extension via environment variables and a custom
IInteractionService.
6. PR #9349 (May 2025) - SPIKE: Spike parameter prompting from CLI
- Summary: A spike PR for parameter prompting, with the idea that parameter resources can fire events to trigger prompting after the CLI backchannel is connected.
7. Issue #8832 (April 2025) - Central configuration/Aspire CLI config commands
- Summary: Discusses adding centralized configuration support to the Aspire CLI, including commands to set and get configuration values. This is relevant to the persistence of prompted values.
8. PR #9676 (June 2025) - Add aspire config commands for managing configuration settings
- Summary: Implements the
aspire config setandaspire config getcommands, providing a way to persist configuration values (potentially including those entered via prompts).
9. Issue #4102 (May 2024) - Make username parameter always be injected
- Summary: Discusses manifest changes to support default values and prompting for parameters like usernames and passwords, including how defaults and secrets should be handled in prompts.
10. Issue #9807 (June 2025) - Prompt for values (the current issue)
- Summary of Comments:
- There is an existing
IInteractionServicewith prompt methods in the CLI. - The design should support both CLI and dashboard UI, with the first provider to respond resolving the prompt.
- Validation should occur in the apphost, with results communicated back to the UI.
- There is interest in persisting prompted values (e.g., to user secrets or config files).
- The current implementation for secrets uses a shared
SecretsStorecomponent.
- There is an existing
Key Takeaways and Conclusions
- Prompting for values at runtime is a recurring theme, with ongoing work to support it in both the CLI and dashboard, and to allow extensions (like VSCode) to provide their own UI for prompts.
- Existing infrastructure: The
IInteractionServicein the CLI already supports prompting for strings, selections, and confirmations. The dashboard is expected to use a gRPC stream to receive and respond to prompt requests. - Validation: There is consensus that validation logic should reside in the apphost, with feedback sent to the UI.
- Persistence: There is interest in persisting prompted values, either in user secrets, appsettings, or a central config file. The new
aspire configcommands and theSecretsStoreare relevant here. - Extensibility: The system is being designed to allow for richer prompts (pick lists, forms) and to work across different environments (CLI, dashboard, VSCode extension).
Most Relevant Issues/PRs for Further Reading
- #1478 - Introduce prompting behavior to inputs for Aspire manifests
- #8915 - Add prompting for parameters in
aspire run,aspire publishandaspire deploy - #9541 - Initial spike of CLI prompting via VSCode extension
- #8832 - Central configuration/Aspire CLI config commands
- PR #9676 - Add aspire config commands for managing configuration settings
- PR #8520 - Interactive prompting for
aspire new - PR #9558 - Prompting for additional template args
- PR #9349 - SPIKE: Spike parameter prompting from CLI
- PR #4102 - Make username parameter always be injected
If you need a more detailed summary of any specific issue or PR, let me know!