[BUG]: Latest ArtifactTool binary from UniversalPackage task is not compatible with CentOS

[nnellanspdl]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

UniversalPackage

Task version

0.243.1

Issue Description

Yes, I know all about CentOS being end of life (unfortunately, we still need to run it for a while).

UniversalPackage is currently downloading ArtifactTool version 0.2.359. This version of ArtifactTool gives an error when running on CentOS: /lib64/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found (required by /opt/azure/_work/_tool/ArtifactTool/0.2.359/x64/artifacttool)

In my previous pipeline runs, the same version of UniversalPackage was downloading an older version of ArtifactTool: 0.2.350. This version worked just fine without any errors.

Is there anything I can do? Is there a way to somehow hard-code the version of ArtifactTool that is downloaded by UniversalPackage?

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

CentOS

Relevant log output

##[error]Error: An unexpected error occurred while trying to download the package. Exit code(1) and error(/opt/azure/_work/_tool/ArtifactTool/0.2.359/x64/artifacttool: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /opt/azure/_work/_tool/ArtifactTool/0.2.359/x64/artifacttool)
##[error]Packages failed to download

Full task logs with system.debug enabled

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

No response

[7fold]

We are having same issue on RHEL 7.9 The latest version of ArtifactTool which worked was 0.2.350

[sadmdbrezack-metabolon]

Same issue centos7. Broke half our build pipelines. Can't find a way to revert it due to the tool downloading the latest.

@v-schhabra can we revert the artifact tools version ?

[7fold]

We spoke with MS Support and their product group is starting a release to rollback all the recent changes they pushed including ArtifactTool. Not sure if it will affect all organizations or just ours.

UPD: They performed a rollback of ArtifactTool to version 0.2.350 and it solved our issue.
UPD2: The rollback is for all organizations for Linux

[github-actions]

In order to consolidate to fewer feedback channels, we've moved suggestions and issue reporting to Developer Community.

[carl-tanner]

With the upcoming end of support for .NET6 we need to move ArtifactTool to run with .NET8 which means we will only run on OSes supported by .NET8. You can use the following workaround to pin the version of ArtifactTool to the final .NET6 version we have published. This isn't supported so if it breaks at some point in the future the recommendation is going to be to move to an OS that is supported. Replace {yourorghere} with the name of your ado organization.

- task: Bash@3
    inputs:
      targetType: 'inline'
      script: |
        account="{yourorghere}";
        osName="linux";
        arch="amd64";
        version="0.2.350";
        downloadPath=$(Agent.TempDirectory);
        destinationZip="${downloadPath}/artifacttool.zip";
        destinationDir="${downloadPath}/artifacttool";

        sourceUrl="https://vsblob.dev.azure.com/$account/_apis/clienttools/artifacttool/download?osName=$osName&arch=$arch&version=$version"

        curl -L -o $destinationZip $sourceUrl

        mkdir -p $destinationDir;

        unzip $destinationZip -d $destinationDir;

        echo "destinationDir: $destinationDir";
        echo "##vso[task.setvariable variable=UPack.OverrideArtifactToolPath;]$destinationDir";
    displayName: 'Download, extract ArtifactTool and set UPack.OverrideArtifactToolPath'

You could also download the tool via the url https://vsblob.dev.azure.com/{yourorghere}/_apis/clienttools/artifacttool/download?osName=linux&arch=amd64&version=0.2.350 (replace {yourorghere} with your ado organization name) and bake it into your linux image. You can set an environment variable UPack.OverrideArtifactToolPath to point to the folder containing the older version.

Next month we will deploy the newer version and your upack tasks will break if you have not implemented this workaround.

[sadmdbrezack-metabolon]

With the upcoming end of support for .NET6 we need to move ArtifactTool to run with .NET8 which means we will only run on OSes supported by .NET8. You can use the following workaround to pin the version of ArtifactTool to the final .NET6 version we have published. This isn't supported so if it breaks at some point in the future the recommendation is going to be to move to an OS that is supported. Replace {yourorghere} with the name of your ado organization.

- task: Bash@3
    inputs:
      targetType: 'inline'
      script: |
        account="{yourorghere}";
        osName="linux";
        arch="amd64";
        version="0.2.350";
        downloadPath=$(Agent.TempDirectory);
        destinationZip="${downloadPath}/artifacttool.zip";
        destinationDir="${downloadPath}/artifacttool";

        sourceUrl="https://vsblob.dev.azure.com/$account/_apis/clienttools/artifacttool/download?osName=$osName&arch=$arch&version=$version"

        curl -L -o $destinationZip $sourceUrl

        mkdir -p $destinationDir;

        unzip $destinationZip -d $destinationDir;

        echo "destinationDir: $destinationDir";
        echo "##vso[task.setvariable variable=UPack.OverrideArtifactToolPath;]$destinationDir";
    displayName: 'Download, extract ArtifactTool and set UPack.OverrideArtifactToolPath'

You could also download the tool via the url https://vsblob.dev.azure.com/{yourorghere}/_apis/clienttools/artifacttool/download?osName=linux&arch=amd64&version=0.2.350 (replace {yourorghere} with your ado organization name) and bake it into your linux image. You can set an environment variable UPack.OverrideArtifactToolPath to point to the folder containing the older version.

Next month we will deploy the newer version and your upack tasks will break if you have not implemented this workaround.

@carl-tanner why not just add a version option to the ADO task ? That would fix this problem for the current users and negate this problem for years

[carl-tanner]

It is an interesting idea and we may implement it in the future.

[nnellanspdl]

It is an interesting idea and we may implement it in the future.

It would be cool to have a holistic approach for all tasks. If a task is getting updated so that it requires .NET 8 support, then it'd be great to have some common "backwards-compatible" or "unsupported" flag on each of those tasks.

I say this because I have a feeling this will just be the first of many tasks to break soon.