v1.5.1 breaks multi subscription login

[matt-cote]

We have a workflow which copies images between container registries in a dev tenant and a prod tenant which is now failing:
ERROR: Subscription '<dev-subscription-name>' not found. Check the spelling and casing and try again.

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: "Azure login dev"
        uses: azure/login@v1
        with:
          client-id: ${{ vars.DEV_CLIENT_ID }}
          tenant-id: ${{ vars.DEV_TENANT_ID }}
          subscription-id: ${{ vars.DEV_SUBSCRIPTION_ID }}

      - name: "Azure login prod"
        uses: azure/login@v1
        with:
          client-id: ${{ vars.PROD_CLIENT_ID }}
          tenant-id: ${{ vars.PROD_TENANT_ID }}
          subscription-id: ${{ vars.PROD_SUBSCRIPTION_ID }}

      - name: Sync
        shell: bash
        run: |
          USERNAME="00000000-0000-0000-0000-000000000000"
          ACCESS_TOKEN=$(az acr login --name <dev-container-registry> --expose-token --output tsv --query accessToken --subscription "<dev-subscription-name>")
          ...
          az acr import --name "$destination" --source "$source_image" --username "$USERNAME" --password "$ACCESS_TOKEN"

Appears to be caused by #377 as pinning to v1.5.0 works.

[YanaXu]

Hi @matt-cote , sorry for this. Please ping to 1.5.0 for a workaround.
You workflow file is clear and helpful. We need some time for your use case to find a better solution.

[matt-cote]

Thanks @YanaXu.

Perhaps consider adding this functionality behind a new input parameter such as clear-account. To implement it as a non-breaking change, it could default to false. Or if you feel that the default should indeed be true then at least we will have the option to disable it for our use case.

[YanaXu]

Hi @matt-cote, It's a good suggestion. We'll add it to our consideration. We have to go through all use cases and see what Azure CLI and Azure PowerShell should do for keeping or clearing the context. Thanks a lot!

[MoChilia]

Hi @matt-cote,
The new version v1.6.0 of azure/login is aimed to fix your issue. Give azure/login@v1.6.0 a try to verify its effectiveness. Check out the pre-release announcement for v1.6.0 here. Any suggestions or feedback are welcome!

[MoChilia]

@charlrvd, @Gibstick, @robcao, I saw you reacted thumbs up in this issue. Are you facing the same issue as @matt-cote? Could you kindly try azure/login@v1.6.0 to verify if it works to your issue?

[matt-cote]

Hi @MoChilia, apologies for the delay. I was able to verify that v1.6.0 works with our use case. Thanks for addressing this issue!

[charlrvd]

It works for me too. Thanks

[MoChilia]

Closing the issue, since this is fixed in v1.6.0 and v1 is pointed to v1.6.0.