-
Notifications
You must be signed in to change notification settings - Fork 194
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
bicep: remove main.parameters.json
caching
#4363
base: main
Are you sure you want to change the base?
Conversation
} | ||
} | ||
} | ||
|
||
if configModified { | ||
if err := p.envManager.Save(ctx, p.env); err != nil { | ||
p.console.Message(ctx, fmt.Sprintf("warning: failed to save configured values: %v", err)) |
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.
In case it isn't clear why ignoring this error may not be ideal:
Suppose that Save()
failed due to flakiness once -- this variable ends up getting re-prompted which is confusing behavior to a user. Straight up failing is better here.
A code demonstration.
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
With this change, we remove the in-memory
main.parameters.json
cache.Backstory: In the old days of
azd
, we introduced in-memory caching formain.parameters.json
with #3155 to avoid a re-prompt when the user declines the prompt "Save the value in the environment for future use?". We added this as a way to communicate withinazd
that "this value is configured for the current azd process lifetime".After #3479, we ended up always saving the values to
config.json
and remove the "Save the value in the environment for future use?" prompt. Since then, the in-memory caching just reduces an extra load from disk, but behaviorally act the same.Fixes #3973, #4310,
Verification
Since #4310 is implemented as an internal
preprovision
hook that setsSERVICE_X_RESOURCE_EXISTS
and shares the same root cause, they would be fixed the same.I modified our storage sample:
And observed both in Portal and the output that
INT_TAG_VALUE
was successfully set to500
.