[Upgrade] Add az upgrade command
#14803
Conversation
fengzhou-msft
force-pushed
the
az_upgrade
branch
from
716040d to
fa07120
Compare
fengzhou-msft
force-pushed
the
az_upgrade
branch
from
fa07120 to
f36f9de
Compare
fengzhou-msft
requested review from
arrownj,
haroldrandom,
jiasli,
jsntcy,
Juliehzl,
mmyyrroonn and
zhoxing-ms
as code owners
|
hi @arrownj could you pls review this PR? thanks |
| try: | ||
| exts = index_data[extension_name] | ||
| except Exception: | ||
| raise CLIError('Extension {} not found.'.format(extension_name)) |
There was a problem hiding this comment.
should this error out or silently swallow? will this func be used other than az upgrade?
There was a problem hiding this comment.
This function is not used in az upgrade now as we always update to the latest extension version. This error happens when users type the wrong extension name.
There was a problem hiding this comment.
ok. I saw it used by list-available-version, so error out is ok. My original point is that az upgrade internal failure should not error out which might impact user in silent upgrading scenario.
There was a problem hiding this comment.
In silent upgrading scenario (auto-upgrade with no prompt), the exit code and stdoutof a command will not be affected, but warnings and errors from az upgrade will be shown in stderr.
| def get_latest_from_github(package_path='azure-cli'): | ||
| try: | ||
| import requests | ||
| git_url = "https://raw.githubusercontent.com/Azure/azure-cli/master/src/{}/setup.py".format(package_path) |
There was a problem hiding this comment.
how to accommodate air-gapped cloud?
There was a problem hiding this comment.
If we are going to support az upgrade in air-gapped cloud, we may not be able to use system package managers. We could put all the packages in a storage account and download/install the corresponding package based on the user system.
There was a problem hiding this comment.
is it necessary to call it out in az upgrade or cloud endpoint discovery design spec?
There was a problem hiding this comment.
yes, will add to cloud endpoint discovery design spec.
| if LooseVersion(VERSIONS['versions']['core']['local']) < LooseVersion(VERSIONS['versions']['core']['pypi']): # pylint: disable=line-too-long | ||
| import subprocess | ||
| import platform | ||
| logger.warning("New Azure CLI version available. Running 'az upgrade' to update automatically.") |
There was a problem hiding this comment.
A warning will not impact the command result for use in script.
| try: | ||
| exts = index_data[extension_name] | ||
| except Exception: | ||
| raise CLIError('Extension {} not found.'.format(extension_name)) |
There was a problem hiding this comment.
ok. I saw it used by list-available-version, so error out is ok. My original point is that az upgrade internal failure should not error out which might impact user in silent upgrading scenario.
| def get_latest_from_github(package_path='azure-cli'): | ||
| try: | ||
| import requests | ||
| git_url = "https://raw.githubusercontent.com/Azure/azure-cli/master/src/{}/setup.py".format(package_path) |
There was a problem hiding this comment.
is it necessary to call it out in az upgrade or cloud endpoint discovery design spec?
| telemetry.set_success("Upgrade stopped by user") | ||
| return | ||
| installer = os.getenv(_ENV_AZ_INSTALLER) | ||
| if installer == 'DEB': |
| if os.geteuid() != 0: # pylint: disable=no-member | ||
| apt_update_cmd.insert(0, 'sudo') | ||
| az_update_cmd.insert(0, 'sudo') |
There was a problem hiding this comment.
What happens if the current user does not have sudo permission?
There was a problem hiding this comment.
An error will be thrown by the Linux system and shown to the user.
There was a problem hiding this comment.
If the error message is given by the OS, and the message does not confuse the user, then I think it is fine~
It may be better that let the users input their admin password to obtain sudo permissions.
| else: | ||
| logger.warning(UPGRADE_MSG) | ||
| if exit_code: | ||
| telemetry.set_failure("CLI upgrade failed.") |
There was a problem hiding this comment.
Could we consider record the error information when the upgrade fails in the telemetry? In this way, we can make statistics on various problems in the future
There was a problem hiding this comment.
Good suggestion. There is an error improvement PR that revamps telemetry. I will work with @houk-ms to improve error tracking here.
Description
Add
az upgradeto update azure-cli on all platforms and with--allenabled, extensions will also be updated.Auto-upgrade can be enabled with
az config set auto-upgrade.enable=yes(default isno). You can also specify whether to update extensions (auto-upgrade.all, default isyes), show prompt message(auto-upgrade.prompt, default isyes). The check against the latest version is done through the local cached~/.azure/versionCheck.jsonfile. The data is valid for 10 days (the expected wait period for the 3-week release cycle of Azure CLI). The check happens after the execution of a command.Add
az extension list-versionscommand to list all available versions of an extension.Testing Guide
History Notes
[Upgrade] Add
az upgradecommand to upgrade azure cli and extensions[Extension] Add
az extension list-versionscommand to list all available versions of an extensionThis checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.