Closed wbreza closed 2 weeks ago
May elevate using
sudo
on some platforms and configurations
bash:
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830 --version '' --verbose --skip-verify
pwsh:
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830' -Version '' -SkipVerify -Verbose
PowerShell install
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830' -Version '' -SkipVerify -Verbose;"
MSI install
powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3830/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"
Nice improvement!
I'm still a little confused on the whole
cachedConfig
vsconfig
thing. I ended up checking out this PR and spending some time in VS Code trying to better understand when it gets set to try to puzzle out what the invariants are, but I didn't feel super confident I understood what's going on.I think the goal here is that we track this so that if PromptForConfig added stuff to it, we could write that stuff into the
env.Config
bag whenReload
was called later. I wonder if it would be possible to say that a responsibility ofPromptForConfig
is to also write an state that needs to become durrable into theenv.Config
at that point, instead of waiting forReload
to be called. If we did that, I wonder if we'd need to trackcachedConfig
as member level state at all.If it does need to stick around, I think it might be helpful to have a little comment about what's going on and how we use it - the
cached
prefix here was a little confusing to me and it wasn't clear at first how it related toconfig
.But either way, this makes the system a lot easier to reason about - thanks for this!
Thanks for the feedback Matt. You are right, except in some cases we don't yet have an environment to write to after we prompt for configuration.
Use case: Some list of environments exist, but you don't have any locally. Some devcenter configuration may be set globally or as part of the project config.
azd env select <env-name>
which exists on the remote.
Resolves #3826
Devcenter configuration can exist at multiple levels for
azd
azd
configurationazure.yaml
azd
envrionment configuration within.azure/<env-name>/config.json
Since the
config
object was being injected as a transient component changes to the config where not getting picked up when changes where made based on user prompts.This PR removes the config from an injected param of a couple components and into a function param for consumed components. This allows the correct config to flow through to the required functions.
In addition to this this enables us to now only save updates to the config based on what has changed from the originally loaded value as part of the
azd
environment configuration.