cli: Breaking change latest CLI version

Hi All, I think this is the 3rd time (or at least the second) in the last couple of months where a mismatch in CLI version between the runner and this CLI task has made workflows fail. Could something be done to make this more reliable since the versions tend to update apart from each other on this task and on the runners.

Hi @rvdlaarschot @marvinbuss @fhavrlent The issue is caused due to mismatch between az cli version on the agent and az cli version being used by azure/cli. This will resolve itself once all the agents have latest azcli version until then we will have to rely on specifically using version 2.29.2 in azure/cli.

Root cause

The is because Azure Login still uses the old ADAL-based Azure CLI 2.29.0 while Azure CLI Action uses the latest MSAL-based Azure CLI 2.30.0.

After the ADAL->MSAL migration (https://github.com/Azure/azure-cli/pull/19853), the latest Azure CLI is not compatible with old versions.

For more info- https://github.com/Azure/azure-cli/issues/20154#issuecomment-958615636

@marvinbuss @rvdlaarschot @vermegi @ajmarks @pdebruin @sazarubin

1. Released a long term fix for any further mismatch issues. Now the default value for azcliversion dynamically points to the version installed on agent. So there will be no mismatch again unless someone explicitly mentions latest. If for some reason there is no version of az cli on the agent then action fall backs to latest.

2. Most of the hosted agents are also updated to 2.30.0.

Please test your scenarios and let us know if you face any more issues.

We had this issue a week ago and set the azcliversion to 2.0.75. This worked for a week. Suddenly, we faced another issue today (the exact time should be one hour ago), it gave another error message: Tried to add the az account set command with no luck…

Hi @vermegi We have raised a PR for new input which if set to true will restrict latest to version available on the agent in order to avoid any mismatch. https://github.com/Azure/cli/pull/57 Let us know if you have any comments on the solution.

@t-dedah Thank you for the details. Upgrading to 2.30.0 works, yes. However, I am still wondering what’s the best way for the future. If I don’t pin the version, then there’s the risk that a newer cli version could break things in our workflow. So I would like to be able to pin, however, doing this produced the issue here.

I have a question based on the following, earlier comment.

“Azure Login still uses the old ADAL-based Azure CLI 2.29.0 while Azure CLI Action”

So the login action uses the cli version that comes with the hosted agent? If so, would it be feasible to add an option to pin also the login action? Then we could avoid the miss-match and would be independent from the hosted agent. What do you think?

@restfulhead You can still pin using azcliversion to any version. But not setting it up on your own will make sure the action will always pick the version already on the agent so there will be no mismatch.

I found out one of the tasks still did a azcliversion: 2.23.0, so that was causing the error. Removed it and all steps appear to be working fine now.

What worked for me was to run az version on azure/loginv1, which returned 2.30.0 (YMMV) and use that as azcliversion like: - uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - run: | az version

- uses: azure/CLI@v1
  with:
    azcliversion: 2.30.0
    inlineScript: |
        az storage blob upload-batch <snip />