Missing dotnet sdk-2.2 about vsts-agent-docker HOT 5 CLOSED

Please Microsoft, fix this issue.

from vsts-agent-docker.

Yes please! Very frustrating then trying to build a release to Azure

from vsts-agent-docker.

While we are waiting for Microsoft to update you can open a shell inside the running docker container and do an inplace upgrade:

docker exec -it container /bin/sh

Then follow this guide: https://dotnet.microsoft.com/download/linux-package-manager/ubuntu16-04/sdk-2.2.101

from vsts-agent-docker.

This is fixed by #169 when it gets merged.

@stepro ping.

It's starting to feel like vsts-agent-docker is a second class citizen and we should start building the images ourselves. This image seems to updated with a huge delay when for example a new dotnet version or TFS version is released.

EDIT: Actually I haven't tried the new-ish .NET Core Tool Installer task. It might be a solution for this issue as well.

from vsts-agent-docker.

Latest images on dockerhub will now have 2.2

If you need the latest versions of software as soon as they are released, I recommend building your own images based off either vsts-agent:ubuntu-14.04 or 16.04 and installing what you need on there. Keeping all the images up to date with the latest of everything, while not moving too fast and breaking people has been a challenge. Additionally, even something small like bumping the dotnet version will have people downstream pulling multiple gigabytes of image layers, depending on how things are ordered (the full standard image is now ~10gb, which is not suitable for people using eg Kubernetes, where containerized agent makes sense).

Overall, Im not inclined to rebuild and push new images for every update of every software that is currently on the image. If there is large need (for example, this issue and community need for dotnet 2.2), I can update that particular software.

It could be set up to automatically build and push on a daily or weekly schedule, which would just pick up changes to the Dockerfiles contributed through PRs, etc, it just puts higher risk on people pulling by tag and not sha, and things unexpected sliding forward.

Ill continue to think about it, but this project has definitely become lower priority as we moved to building vm-based environments (https://github.com/Microsoft/azure-pipelines-image-generation) which have grown far too bulky to be useful in a container scenario (the full set of software installed would bloat these images by several 10s of more GBs)

from vsts-agent-docker.