Self-hosted runner cleanup: use Ubuntu instead of azure/cli action

[dennisameling]

The azure/cli GitHub Action runs in a Docker container with Alpine or Azure Linux, meaning that many tools like node and gh (which we rely on) aren't available.

Since the Azure CLI is available in the GitHub-hosted ubuntu-latest image anyway, let's leverage that instead. In the end, it has all the other tools we need as well.

Ref: https://github.com/actions/runner-images/blob/ce2a3e8e67858dc8c3dd77aca6b29e2956d934ed/images/ubuntu/Ubuntu2404-Readme.md?plain=1#L105

[dennisameling]

@dscho I need some help here regarding the Azure Credentials. Currently, you have an AZURE_CREDENTIALS secret in this repo/org, which is most likely a JSON payload, as mentioned here. It'll look something like this:

{
    "clientSecret":  "******",
    "subscriptionId":  "******",
    "tenantId":  "******",
    "clientId":  "******"
}

If we want to invoke az login directly, which I did in this PR, we'll need to pass all of these individually. I'd opt for having them in dedicated secrets, allowing us to use them like this:

az login --service-principal -u ${{ secrets.AZURE_CLIENT_ID }} -p ${{ secrets.AZURE_CLIENT_SECRET }} --tenant ${{ secrets.AZURE_TENANT_ID }}
az account set --subscription ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Would it be possible for you to set up those secrets? If not (or if it's too much work to do), I can most likely just extract the individual values from the JSON using jq, but I'm worried that GitHub might not mask those individual extracted values in the logs unless we do an ::add-mask::{value} for each individual value first. Having them in separate secrets just feels a bit cleaner and easier to work with to me, but it can be worked around for sure.

WDYT?

Also, here's a sample run, which obviously failed because of the missing secrets.

[dscho]

@dscho I need some help here regarding the Azure Credentials. Currently, you have an AZURE_CREDENTIALS secret in this repo/org, which is most likely a JSON payload, as mentioned here. It'll look something like this:

{
    "clientSecret":  "******",
    "subscriptionId":  "******",
    "tenantId":  "******",
    "clientId":  "******"
}

If we want to invoke az login directly, which I did in this PR, we'll need to pass all of these individually. I'd opt for having them in dedicated secrets, allowing us to use them like this:

az login --service-principal -u ${{ secrets.AZURE_CLIENT_ID }} -p ${{ secrets.AZURE_CLIENT_SECRET }} --tenant ${{ secrets.AZURE_TENANT_ID }}
az account set --subscription ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Would it be possible for you to set up those secrets? If not (or if it's too much work to do), I can most likely just extract the individual values from the JSON using jq, but I'm worried that GitHub might not mask those individual extracted values in the logs unless we do an ::add-mask::{value} for each individual value first. Having them in separate secrets just feels a bit cleaner and easier to work with to me, but it can be worked around for sure.

That's too bad... the problem is that the JSON is produced when registering with Azure, and I'd like to keep it copy-pasteable.

How about using a github-script step to extract those values instead of using jq? That should take care of the masking very easily, as well as of setting the values as step outputs.

[dennisameling]

How about using a github-script step to extract those values instead of using jq? That should take care of the masking very easily, as well as of setting the values as step outputs.

@dscho great suggestion! I've applied the changes. Here's a successful workflow run. Starting another workflow run confirmed that no VMs are left after the cleanup 👍🏼

[dscho]

Awesome!