login: 1.6.0 versions Pre login Fails on self hosted runners

Our workers are ephemeral and starts up in k8s pods upon request. I.e. The runtime environment are clean Linux containers that are killed when the pipeline finishes.

Hi all, v1 has been updated to v1.6.1. Thank you again for bringing this issue to our attention, sharing your use cases, and helping us test! cc @kristeey, @ohbriansung, @sblackstone, @martin-traverse, @VincentVerweij, @roschart.

Confirmed that v1.6.1 is working for self-hosted runner without pre-installation of az cli. Still getting a warning but it’s not breaking the workflow anymore:

Warning: Login cleanup failed with 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.. Cleanup will be skipped.

@nickwb, correct me if I’m wrong. Current issue #403 is describing a use scenario like this: the workflow file runs on a fresh clean image (not a VM); the image is based on linux and without az installed; the workflow file contains one job; the job will install az and call azure login action afterwards. Is this your use scenario? If it’s not, please provide the details of yours.

This is also my scenario.

I suspect many people who this is impacting are using https://github.com/actions/actions-runner-controller

Hi @kristeey, @VincentVerweij, @mattloretitsch-od, @nuryupin-kr, @ohbriansung, @nickwb, we have created a preview test tag v1.6.1. Could you kindly try azure/login@v1.6.1 to verify if the fix works for you?

@nickwb, correct me if I’m wrong. Current issue #403 is describing a use scenario like this: the workflow file runs on a fresh clean image (not a VM); the image is based on linux and without az installed; the workflow file contains one job; the job will install az and call azure login action afterwards. Is this your use scenario? If it’s not, please provide the details of yours.

Hi all,

Sorry for introducing this issue. First, please pin to v1.5.1 to workaround this issue.

What we’ll do next: Release a new fix in v1.6.1. If it’s OK, align v1 to v1.6.1.

What we want to clarify:

• v1.6.0 fixes a security issue. It cleans login cache, which is important for regular use scenarios, especially for self-hosted runners on VMs.
• We do understand it may change the workflow since we add pre and post steps. That’s why we create an announcement #399 to collect your feedbacks. We’d like to collect your advice on this: how to notify you that there will be a new version of this action? Please leave a comment if you have a better suggestion.
• We won’t introduce breaking changes in v1. If we do find it’s a breaking change, we’ll fix it. No worries.
• We do not expect so many self-hosted runner use cases. To be honest, there is still a long way to well support self-hosted runners. There are too many different use scenarios for self-hosted runners. Actually, we’re glad to see you provide your use scenarios here and we definitely will add them to our support paths.

@bb-froggy, your use case is not strange, and I think it’s reasonable. We are now exploring the use cases of azure/login within GitHub Actions. There are so many scenarios! And from my perspective, these scenarios are also fair. We aspire to broaden our support to encompass these cases more stably. Thank you for bringing your use case to our attention!

Additionally, installing az by azure/login is not a straightforward one and there are numerous factors to consider, just as your mentioned, many users wouldn’t like to do this. We will keep your use case in mind and continue collecting more use cases to try our best to avoid breaking your scenarios while improve the user experience of azure/login.

Hi @kristeey, @VincentVerweij, @mattloretitsch-od, @nuryupin-kr, @ohbriansung, @nickwb, we have created a preview test tag v1.6.1. Could you kindly try azure/login@v1.6.1 to verify if the fix works for you?

We have tested version v1.6.1 and it works well in our environment. It would be ideal if you could point version v1 to v1.6.1.

Hi @kristeey, @VincentVerweij, @mattloretitsch-od, @nuryupin-kr, @ohbriansung, @nickwb, we have created a preview test tag v1.6.1. Could you kindly try azure/login@v1.6.1 to verify if the fix works for you?

The team and I just implemented the v1.6.1 tag and it allows us to continue our deployments, thanks for that. As expected the following warning is given in the Pre step: Warning: Login cleanup failed with 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.. Cleanup will be skipped.

We have a multi-cloud project with a reusable workflow for integration that we use for all 3 cloud targets. The Azure auth step is conditional and only runs when the matrix build target is Azure. This change doesn’t just break our Azure integration, it breaks GCP and AWS as well because the pre-step is still generated even when the conditional Azure auth step doesn’t run.

We have upgraded to 1.6.1 which does let the build pass but is still generating warnings, and again those warnings appear for all three cloud targets not just Azure. It would be great if there was a way to disable the pre/post steps, we don’t need them for our setup, the build container is destroyed anyway. At the very least we should be able to turn them off with the same condition we use to control the login step itself.

Also +1 for making v1 point to v1.6.1, currently using @v1 is still broken for us.

https://github.com/finos/tracdap/blob/main/.github/workflows/integration-cloud.yaml

@martin-traverse, v1 will be pointed to v1.6.1 soon. Thanks for sharing your use case with us. It’s really helpful. We will consider how to optimize the pre and post steps.

We have a multi-cloud project with a reusable workflow for integration that we use for all 3 cloud targets. The Azure auth step is conditional and only runs when the matrix build target is Azure. This change doesn’t just break our Azure integration, it breaks GCP and AWS as well because the pre-step is still generated even when the conditional Azure auth step doesn’t run.

We have upgraded to 1.6.1 which does let the build pass but is still generating warnings, and again those warnings appear for all three cloud targets not just Azure. It would be great if there was a way to disable the pre/post steps, we don’t need them for our setup, the build container is destroyed anyway. At the very least we should be able to turn them off with the same condition we use to control the login step itself.

Also +1 for making v1 point to v1.6.1, currently using @v1 is still broken for us.

https://github.com/finos/tracdap/blob/main/.github/workflows/integration-cloud.yaml

Hi @kristeey, @VincentVerweij, @mattloretitsch-od, @nuryupin-kr, @ohbriansung, @nickwb, we have created a preview test tag v1.6.1. Could you kindly try azure/login@v1.6.1 to verify if the fix works for you?

1.6.1 resolves my issue, will v1 be pointed to v1.6.1?

@Topper1987, your issue is not related to #403, please check the solution in #404 (comment).

Thank you! You are right, I missed that. It solved our issue.

@Topper1987, your issue is not related to #403, please check the solution in https://github.com/Azure/login/issues/404#issuecomment-1895627898.

@JasonRSeequent , it seems a different issue. Could you create a new issue and provide your workflow file and debug log? Thanks.

We install az cli in a step right before calling azure/login step. Could you guys point your v1 tag to same commit as 1.5.1?

Same issue here. We also use empty Linux containers, on which in one of the steps of the workflow we install the Azure CLI. But now, this pre step gives an error because it is not available yet at time of executing the pre step. Basically messing up our deployment process.

Wouldn’t it be an idea of bumping the major number in case of such change, what is considered as breaking?