-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix persist with default value params in aspire #4524
fix persist with default value params in aspire #4524
Conversation
Must we persist the value in the config like this? Naively it feels to me that we could fetch it from the manifest or something when we needed it. I think this is an okay solution to this problem - but I'm still trying to wrap my head around the full scope of things and how it interacts with where we are moving long term. I'm not 100% sure exactly how this all hangs together when the thing that references the value is a This feels like a place where our strategy of "push all prompting for all values across all deployments for the app into the I'm not sure if I love |
cli/azd/test/functional/testdata/samples/aspire-full/Directory.Build.props
Show resolved
Hide resolved
I did consider adding a new way for azd to search for parameters (when need it), but that would lead us into having 2 ways of looking for params:
I think adding 2) increases the complexity v/s using the same pattern we are currently using. The only thing I had to make in this PR is to tell azd when to persist the values, as we don't want to persist everything in azd.config.json by default. Another NOTE: To get a parameter value defined with DefaultValue in the AppHost, we don't ONLY need to read the default value from the Manifest. We also need to check if the value is not overridden by the user using an ENV VAR. AZD is currently handling this with 1). A Parameter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We talked about this a bunch in person as well - I think this moves us in the right direction. For the record, we both didn't feel "great" about how this hangs together, but we sort of felt it was the best we could do given how stuff is organized today.
Over time I suspect we'll think more about the underlying deployment workflow graph we are constructing and how values flow from one place to another and maybe we can do this in a better way than squireling the values in config
but this seemed like the best story we have today.
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
fix: #4523
This PR adds a new azd metadata type
NeedForDeploy
which is automatically set to bicep input parameters using a default value in the AppHost.With this metadata, azd makes a copy of the defaultValue (or the value if overriden with one ENV VAR) and persists it into the azd configuration.
This allows azd to find the value for the parameter if it is needed during deployment as an Argument.