You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Was there a major upgrade to this script on 1/21/2026 that broke many build pipelines? #620
We've had this code in our dockerfiles for a long time
FROM mcr.microsoft.com/dotnet/sdk:8.0-azurelinux3.0 as builder
RUN curl -L https://aka.ms/install-artifacts-credprovider.sh | bash
ARG VSS_NUGET_ACCESSTOKEN
ARG VSS_NUGET_URI_PREFIXES
ARG VSS_NUGET_EXTERNAL_FEED_ENDPOINTS
COPY nuget.config ./
RUN dotnet tool install --global --configfile nuget.config --verbosity detailed dotnet-trace
...
Since today afternoon (1/21/26) those builds are all failing with errors like this:
##[error]#10 0.579
##[error]#10 0.611
##[error]#10 0.626 No version specified, using latest release.
##[error]#10 0.626 Fetching versioned release install script from https://github.com/microsoft/artifacts-credprovider/releases/latest/download/installcredprovider.sh
##[error]#10 0.874 Fetching release metadata from https://api.github.com/repos/microsoft/artifacts-credprovider/releases/latest
##[error]#10 1.054 bash: line 80: awk: command not found
##[error]#10 ERROR: process "/bin/sh -c curl -L https://aka.ms/install-artifacts-credprovider.sh | bash" did not complete successfully: exit code: 127
##[error]------
What just happened? Every single OneBranch build is failing now (Microsoft internal). I see the script now contains awk calls, but I don't know what it looked before. This was very sudden.
How do we fix this? I can see hundreds of docker files in ADO that follow this pattern.
Reacted by judellam, Joel Degerman, Jonas Lindberg, Raúl Piracés Alastuey, Ron Levi, Justin Hull, Valeriia Nesterova and Alex Cortelyou
Adding this (or equivalent) in the dockerfile before running the script fixes the problem:
RUN tdnf install -y gawk
However, I would like to know how this change was managed, since the impact of a breaking change in a script exposed to the consumers through a non-versioned address https://aka.ms/install-artifacts-credprovider.sh is potentially huge.
2.0.0 was released and marked as latest yesterday, and it includes the known breaking changes we announced in #614. The awk dependency causing failures on minimal Linux containers was not an expected breaking case.
“However, I would like to know how this change was managed, since the impact of a breaking change in a script exposed to the consumers through a non-versioned address https://aka.ms/install-artifacts-credprovider.sh is potentially huge.”
The install scripts fetch the latest GitHub release by default, so once we updated the release, the scripts effectively updated as well. While the aka.ms links point to the latest install script asset, the scripts themselves are “versioned” because they ship inside each GitHub release asset.
These kinds of breakages highlight the long‑standing issues with the historical install scripts especially for containers and build scenarios. Going forward, we strongly recommend moving to installing the artifacts-credprovider as a dotnet tool (requires .NET 9.0.2 or later).
Instead of installing awk (slow), you can use the previous version of the installer: RUN curl -L https://github.com/microsoft/artifacts-credprovider/releases/download/v1.4.1/installcredprovider.sh | bash
@fstugren and others who run into this before they can upgrade to dotnet 10:
Instead of installing awk (slow), you can use the previous version of the installer: RUN curl -L https://github.com/microsoft/artifacts-credprovider/releases/download/v1.4.1/installcredprovider.sh | bash
alternatively RUN curl -L https://github.com/microsoft/artifacts-credprovider/releases/download/v2.0.0/installcredprovider.sh | bash will use the latest script and assets as awk is not in this script but the v2.0.0/installcredproviderrekease.sh where the sha validation occurs
Activity
fstugren commentedon Jan 22, 2026
Adding this (or equivalent) in the dockerfile before running the script fixes the problem:
However, I would like to know how this change was managed, since the impact of a breaking change in a script exposed to the consumers through a non-versioned address
https://aka.ms/install-artifacts-credprovider.shis potentially huge.embetten commentedon Jan 22, 2026
2.0.0 was released and marked as latest yesterday, and it includes the known breaking changes we announced in #614. The awk dependency causing failures on minimal Linux containers was not an expected breaking case.
The install scripts fetch the latest GitHub release by default, so once we updated the release, the scripts effectively updated as well. While the aka.ms links point to the latest install script asset, the scripts themselves are “versioned” because they ship inside each GitHub release asset.
These kinds of breakages highlight the long‑standing issues with the historical install scripts especially for containers and build scenarios. Going forward, we strongly recommend moving to installing the artifacts-credprovider as a dotnet tool (requires .NET 9.0.2 or later).
fstugren commentedon Jan 22, 2026
embetten - thanks for getting back to me. Would you recommend we replace the call to:
with something like:
And this would work only if we switch the image to one that uses .Net 9 as in:
embetten commentedon Jan 22, 2026
100 % but again only if you use a dotnet version where NuGet supports the dotnet tool plugin discovery (.NET 9.0.2 or later) see: https://learn.microsoft.com/en-us/nuget/reference/extensibility/nuget-cross-platform-plugins#path-discovery and the dotnet sdk is already installed so you can run the
dotnet tool installcommand.Users on earlier versions of .NET or scenarios without the .NET sdk will not be able to use the dotnet tool install.
fstugren commentedon Jan 22, 2026
Thanks. I will be recommending to the team to install
awkif they're still on .Net8, and once they update to .Net 9 switch to the .Net tool installer.docs: upate docker sample with dotnet tool install (#622)
acortelyou commentedon Jan 26, 2026
Fritz Stugren (@fstugren) and others who run into this before they can upgrade to dotnet 10:
Instead of installing awk (slow), you can use the previous version of the installer:
RUN curl -L https://github.com/microsoft/artifacts-credprovider/releases/download/v1.4.1/installcredprovider.sh | bashacortelyou commentedon Jan 26, 2026
I was hoping to side-step the bash installer issue by using powershell, but that doesn't work either: #631
embetten commentedon Jan 27, 2026
alternatively
RUN curl -L https://github.com/microsoft/artifacts-credprovider/releases/download/v2.0.0/installcredprovider.sh | bashwill use the latest script and assets as awk is not in this script but the v2.0.0/installcredproviderrekease.sh where the sha validation occursfstugren commentedon Jan 28, 2026
embetten - thanks, we fixed by installing awk, it's good to have the alternative to avoid that and go refer straight to the versioned file path.
docs: upate docker sample with dotnet tool install (#622)
scripts: check for awk and add sed fallback in installcredproviderrel…
scripts: check for awk and add sed fallback in installcredproviderrel…