UniversalPackages@0 fails in container job

[fgervais]

It seems I cannot run a UniversalPackages@0 task in a container job unless I add a bunch of dependencies to my container image.

I would assume the task to be self sufficient, no?

As an example, when trying to download a package I get:

Error: An unexpected error occurred while trying to download the package. Exit code(136) and error(Failed to load ؖ!�, error: libunwind.so.8: cannot open shared object file: No such file or directory
Failed to bind to CoreCLR at '/__t/ArtifactTool/0.2.88/x64/libcoreclr.so')
Packages failed to download

[TingluoHuang]

@fgervais
looks like that task contains a dotnet core executable, which requires OS dependencies. :(
task suppose to be self sufficient.

@bryanmacfarlane @vtbassmatt FYI,

[mitchdenny]

Thanks for reporting this. The Universal Package task currently depends on Artifact Tool which is part of the hosted tool cache, and it is indeed a .NET Core app, although it is self contained. The libraries that are missing are not .NET Core, they are libraries that .NET Core builds.

We'll discuss how we want to approach this scenario on the Azure Artifacts team and respond to this thread. @TingluoHuang this is one of the differences between the Pipeline Artifacts artifact type and Universal Packages. The Pipeline Artifacts type depends on an agent plug-in which from what I understand does work in a container (will test).

We didn't take that approach with Universal Packages. We might need to revisit that decision.

[mitchdenny]

At this point in time running the Universal Package task within a container only works if you install the dependencies that are required for .NET Core. This is a known issue that will require some design changes to overcome.

For the time being if you use a container that is capable of running .NET Core then publishing or downloading a Universal Package should work.