Azure / azure-devops-cli-extension

Azure DevOps Extension for Azure CLI
https://docs.microsoft.com/en-us/cli/azure/ext/azure-devops/?view=azure-cli-latest
MIT License
617 stars 239 forks source link

[Feature Request] Install keyring by default or offer a way to install keyring without causing error messages #1367

Open jessehouwing opened 9 months ago

jessehouwing commented 9 months ago

Is your feature request related to a problem? Please describe.

When calling az devops login for the very first time, it installs pythons keyring package. For some reason that's not included in the default setup. This adds needless time to a first invocation of az devops login on the GitHub Hosted Runners and Azure Pipelines.

You can force the installation of keyring using

echo "dummy" | az devops login
az devops logout

On the GitHub/Azure Pipelines hosted runner the provisioning of the image happens on a non-interactive session and az devops login fails with an error along those lines.

ERROR: (1312, 'CredRead', 'A specified logon session does not exist. It may already have been terminated')

Unfortunatly, az devops doesn't provide a clean way to install keyring during installation or through a command other than catching the failed login.

Describe the solution you'd like Either azdevops should preinstall keyring during normal installation of the extension. It's unclear why it's not included in the first place.

Or there should be a clean way to run az devops install-dependencies or something to have it download its dependencies in a provisioning scenario.

I grabbed the following lines from the code:

$pythonPath = resolve-path (join-path ([System.IO.Path]::GetDirectoryName((Get-Command az).Path)) "..\python.exe")
Invoke-ValidateCommand -Command "& '$pythonPath' -m pip install keyring~=17.1.1 --target '$env:AZURE_EXTENSION_DIR\azure-devops' -vv --disable-pip-version-check --no-cache-dir"  

and it works. But since there is no way to grab the correct version of keyring from anywhere other than the sourcecode of az devops, it's a very brittle contract.

For now we're looking into just swallowing any message printed by az devops login. But that's of course also a brittle contract.

cli.azext_devops.dev.common.pip_helper: installing keyring~=17.1.1
cli.azure.cli.core.extension.operations: Running: ['C:\\Program Files\\Microsoft SDKs\\Azure\\CLI2\\python.exe', '-m', 'pip', 'install', 'keyring~=17.1.1', '--target', 'C:\\Users\\WDAGUtilityAccount\\.azure\\cliextensions\\azure-devops', '-vv', '--disable-pip-version-check', '--no-cache-dir']

Additional context

I know I could also set an environment variable with an access token instead of calling az devops login, unfortunately that also adds a 10 second delay on the GitHub Hosted Runner / Azure Pipelines runner as it tries to run az login, sees it fail and only then reverts to using the token supplied on the commandline.