Azure-devops-cli-extension: Artifacttool doesn't work on docker image

[rorpage]

The latest version on Docker Hub is 0.1.3: https://hub.docker.com/r/microsoft/vsts-cli/tags/

Here's the page I'm referring to: https://docs.microsoft.com/en-us/cli/vsts/install?view=vsts-cli-latest

[atbagga]

@tedchamb Is there a reason we specify a specific docker version tag, rather than 'latest'?

[rorpage]

If I may chime in, I pulled 0.1.3 as the Universal Packages piece of the CLI wasn't in 0.1.0.

I can open a separate issue for this, but the artifacttool doesn't appear to install correctly in 0.1.3. Perhaps it's .NET Core and the base is Python Alpine?

[tedchamb]

@atbagga I agree, we shouldn't be specifying the version in those commands. @wnjenkin, is this something you can update?

@zarenner, can you investigate the artifacttool issue? Let me know if we need to create a new image.

[rorpage]

@tedchamb @wnjenkin Is this something I could do for Hacktoberfest? I'm also more than happy to help @zarenner with a new image too!

[rorpage]

Here's the message I get in my container:

Universal Packages is currently in preview.
[Errno 2] No such file or directory: '/root/.vsts/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.74/artifacttool': '/root/.vsts/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.74/artifacttool'
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/knack/cli.py", line 197, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/local/lib/python3.6/site-packages/knack/invocation.py", line 172, in execute
    cmd_result = parsed_args.func(params)
  File "/usr/local/lib/python3.6/site-packages/knack/commands.py", line 105, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/knack/commands.py", line 203, in _command_handler
    result = op(client, **command_args) if client else op(**command_args)
  File "/usr/local/lib/python3.6/site-packages/vsts/cli/package/common/universal.py", line 41, in publish_package
    return artifact_tool.publish_universal(team_instance, feed, name, version, description, path)
  File "/usr/local/lib/python3.6/site-packages/vsts/cli/package/common/artifacttool.py", line 30, in publish_universal
    return self.run_artifacttool(team_instance, args, "Publishing")
  File "/usr/local/lib/python3.6/site-packages/vsts/cli/package/common/artifacttool.py", line 44, in run_artifacttool
    proc = self._tool_invoker.run(command_args, new_env, initial_progress_message, self._process_stderr)
  File "/usr/local/lib/python3.6/site-packages/vsts/cli/package/common/external_tool.py", line 68, in run
    self.start(command_args, env)
  File "/usr/local/lib/python3.6/site-packages/vsts/cli/package/common/external_tool.py", line 38, in start
    env=env)
  File "/usr/local/lib/python3.6/subprocess.py", line 709, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1344, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: '/root/.vsts/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.74/artifacttool': '/root/.vsts/cli/tools/artifacttool/ArtifactTool_linux-x64_0.2.74/artifacttool'

[tedchamb]

@geverghe, fyi regarding @rorpage 's offer to help (see above).

[geverghe]

Thank you @rorpage for the offer. @zarenner is looking into this.

[rorpage]

Absolutely! Sounds great.

[zarenner]

Sorry for the delay here. I tried running the existing ArtifactTool with various compat libraries on Alpine with no success.

There's a bunch of stuff needed to get ArtifactTool (which is dotnet-based) officially supported on Alpine:

1. ArtifactTool needs to move to .NET Core 2.1 and build self-contained for alpine-x64.
2. We need to make a change in VSTS CLI to send additional information to identify itself as alpine (right now it just sends that it's Linux and x64 😢)
3. We need to deploy a tiny bit of service logic to send down the alpine variant of artifacttool.
4. We very likely need to add additional dotnet dependencies to the vsts-cli docker image.

1 is done, 2 is pending PR, 3 is pending deployment.
edit: updated status

[mitchdenny]

Thanks for reporting the issue. @zarenner would the distro package change you have in #324 at the moment resolve this?

[zarenner]

@mitchdenny It's necessary but not quite sufficient. Our service has been able to serve out the alpine edition of ArtifactTool, and we're building for alpine, but we're not currently publishing it. Let's talk with Owen to get it publishing.

I'll re-test and merge #324 in the next day or two, now that we've discussed with the CLI owners that adding the distro package is OK.

Hopefully that should be all that's needed - IIRC there weren't actually additional deps that needed to be added to the docker image, but obviously need to confirm that again.

[mitchdenny]

OK - do we have a bug tracking this internally already?

[zarenner]

No, feel free to create (although I'd also love to just get it tied off quickly too :-))

[mitchdenny]

We've flighted the alpine build so hopefully you can test out your PR end to end.

[zarenner]

Everything is now working (and has been for a bit, sorry for the lack of update), except that the azure-cli docker image is missing 2 required dependencies: libintl and icu-libs

That is, the following works today:

docker run -it mcr.microsoft.com/azure-cli
az extension add --name azure-devops
apk update
apk add libintl icu-libs
az login
az artifacts universal publish --organization https://dev.azure.com/{organization} --feed "{feed}" --name "the-bin-folder" --version "0.0.1" --path bin

I've filed https://github.com/Azure/azure-cli/issues/9276 to see if we can get these dependencies into the azure-cli image

[atbagga]

@zarenner I see the Azure CLI dependency issue that you filed has been fixed and closed.
Is it OK to close the Docker image related issues now?

[zarenner]

Yes, with recent azure-cli images this is completely resolved as far as I can tell. Closing.