[Issue] Build agents can't download azd

[mip1983]

This morning (since about 9am GMT), I can't run deployments as my Azure DevOps pipeline can't complete the 'Setup Azure Developer CLI' build step. It's trying to access this file:

https://azd-release-gfgac2cmf7b8cuay.b02.azurefd.net/azd/standalone/release/latest/azd-windows-amd64.zip

If I just past that URL into a browser, it's struggling to download on my machine getting low KB/s before failing. This is happening on the MS hosted cloud based build agent and locally.

[mip1983]

Still broken, seems to download ok for me now, but the build agent still sits a long time on the build step, never outputs the install path or version:

Then subsequent steps can't find azd:

This is on both a local build agent and 'windows-latest'

[rajeshkamal5050]

@danieljurek looks like the new CDN migration changes?

[danieljurek]

@mip1983 thanks for filing. We did migrate to a new CDN last week. I'm going to keep looking into this issue.

Can you share with me the location of the machines where you're seeing these issues?

I would expect to see these connection speed and network drop issues if traffic were directed to a location on another continent, but Front Door caching should be delivering the file from a host that is closer to your location.

[mip1983]

@mip1983 thanks for filing. We did migrate to a new CDN last week. I'm going to keep looking into this issue.

Can you share with me the location of the machines where you're seeing these issues?

I would expect to see these connection speed and network drop issues if traffic were directed to a location on another continent, but Front Door caching should be delivering the file from a host that is closer to your location.

Hi, the self hosted agent is in south UK, the windows-latest agent I don’t know, but our Azure DevOps location is also uk south.

Testing directly on the self hosted agent, the download speed has recovered (less than 1s) yet the build was still behaving as the screenshots, I.e it spends a long time, doesn’t output the down location or azd version as it would normally (though doesn’t fail the step) then azd isn’t available on the next step.

[danieljurek]

@mip1983 thanks for the info. We are continuing to investigate.

As a temporary mitigation you can use the install script directly with an override to the download location of the old CDN. This task will work on Windows, Linux, and MacOS agents that have pwsh installed (all hosted Azure DevOps images):

      - pwsh: |
          Invoke-RestMethod 'https://aka.ms/install-azd.ps1' -OutFile install-azd.ps1
          ./install-azd.ps1 -BaseUrl 'https://azdrelease.azureedge.net/azd/standalone/release'
          Remove-Item ./install-azd.ps1

          if ($IsWindows) {
            # Prepend install location to PATH on Windows
            Write-Host "##vso[task.prependpath]$($env:LocalAppData)\Programs\Azure Dev CLI"
          }
        displayName: Install azd (mitigation)

Because we're migrating away from the Edgeio CDN the azdrelease.azureedge.net host could become unstable in the future so this solution is temporary.

I'm going to keep this issue open until I have more information about the status of the CDN in the UK region.

[mip1983]

Thanks for the work around. I've run one test build this morning with the original setup and that's worked as normal. Hopefully it'll remain that way, but will update here if the issue returns.

[danieljurek]

@mip1983 -- have you seen any reliability problems since yesterday?

If not, I'll close this issue out. We're seeing the situation is resolved on our side.