azure/login@v1 and azure/CLI@v1 should be consistent

[jludvice]

Please align azure/login@v1 and azure/CLI@v1. It's really strange and not user friendly.

Given workflow where I first use azure/CLI@v1 to show current az version and then use azure/login@v1 it behaves quite weird.

az version actually shows latest version because this action actually pulls and runs microsoft docker image with azure cli,
but then the azure/login@v1 action fails because this one relies on az command being installed on self-hosted github runner.

    - name: show az version
      uses: azure/CLI@v1
      with:
        inlineScript: |
          az version

    - uses: azure/login@v1
      with:
        creds: ${{ secrets.SECRET }}

In my case the azure/login@v1 will fail on az command not being available because my runners are quite clean and az is not installed.

What is the reason to forcing users to both manage az on the hosts and also require having docker installed and pull docker images for actually performing any az actions?

I believe azure/login and azure/cli should use consistent approach in this case.

[jludvice]

Example of az login failure when az is not installed on linux github self-hosted runner.

Run azure/login@v1
  with:
    creds: ***
    enable-AzPSSession: false
    environment: azurecloud
    allow-no-subscriptions: false
  env:
    NOT_RELEVANT: "..."

Error: Az CLI Login failed. Please check the credentials. For more information refer https://aka.ms/create-secrets-for-GitHub-workflows
Error: Error: Unable to locate executable file: az. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

[AlexDCraig]

This is happening to me as well on my self-hosted runner.

[orenzi-tr]

This is happening to me as well on my self-hosted runner.

I also had this issue running on a windows Github self-hosted runner.
I managed to get it to work by changing the Github-runner server "Log On" as setting to run under a local user account instead of running as Local System.

This isn't an ideal solution on my part, so I guess its something with windows PATH issue if it can't find the executable.

[github-actions]

This issue is marked need-to-triage for generating issues report.

[github-actions]

This issue is idle because it has been open for 14 days with no activity.

[khalidiml]

I am also facing this problem. I have checked the credentials. The creds are valid.

- uses: azure/login@v1
  with:
      creds: ${{ env.AZURE_CREDENTIALS }}

Error: Az CLI Login failed. Please check the credentials. For more information refer https://aka.ms/create-secrets-for-GitHub-workflows
Error: Unable to locate executable file: az. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

[github-actions]

This issue is idle because it has been open for 14 days with no activity.

[davetapley]

I just lost an hour because of the Please check the credentials. message,
when in reality it was just that the act runner I was using didn't have az installed 😞

Even if we can't get self installing, can we at least check for az and abort with a clearer error message?
I think it's as simple as checking catching here:

login/src/main.ts

Line 44 in db989b3

azPath = await io.which("az", true);

Because which says:

If you check and the tool does not exist, it will throw.

Which currently gets caught by this catch all whose error message doesn't actually check the error 🤢 :

login/src/main.ts

Lines 209 to 211 in db989b3

	catch (error) {
	if (!isAzCLISuccess) {
	core.setFailed("Az CLI Login failed. Please check the credentials. For more information refer https://aka.ms/create-secrets-for-GitHub-workflows");

[github-actions]

This issue is idle because it has been open for 14 days with no activity.

[BALAGA-GAYATRI]

Azure/login action is only responsible for logging into azure. Azure/cli has a different approach of pulling the latest docker image and executing cli commands. While the design of both the actions is different currently az needs to be present on the runner to leverage login action. Inorder to help the users to figure out the reason for failure, we have added this statement in the error response and released a new version v1.4.3 and updated v1 version also with the same.

[apgapg]

But how do we install az on self hoster runner?
I cant find much straight forward docs