When, where and how does Visual Studio 2017 set the DOCKER_BUILD_SOURCE environment variable

When creating a new .NET core application with docker support in Visual Studio 2017 it creates a number of docker-compose.yml files. The docker-compose.vs.debug.yml and the release variant both contain contain a reference to an environment variable named DOCKER_BUILD_SOURCE:

version: '2'

    image: app:dev
        source: ${DOCKER_BUILD_SOURCE}
      - ./app:/app
      - ~/.nuget/packages:/root/.nuget/packages:ro
      - ~/clrdbg:/clrdbg:ro
    entrypoint: tail -f /dev/null
      - "com.microsoft.visualstudio.targetoperatingsystem=linux"

The purpose of this variable seems to be a reference to the source directory, however, it always seems to be empty.

I was unable to find more detailed info on this subject… Does anyone have an idea or a pointer to some docs?

  • Docker - Handling multiple services in a single container
  • Suse Linux docker file
  • Initialize docker volume ony once
  • How do I set rack and datacenter name for scylladb using docker?
  • Running services (upstart/init.d) in a container
  • Docker swarm nodes on private networks?
  • UnknownHostException in Kubernetes-Container
  • Container NAMES when deploying with Docker
  • How to enable secure communication between Docker Containers in a Swarm?
  • how to update docker in coreos
  • Docker Commit Created Images and ENTRYPOINT
  • Which Docker images will run on Kubernetes?
  • 2 Solutions collect form web for “When, where and how does Visual Studio 2017 set the DOCKER_BUILD_SOURCE environment variable”

    I believe it has to do with doing some setup that can be used with Visual Studio Team Services CI/CD. However when run locally, that value is empty and if you look at the docker file, you see that if the value is empty, it substitutes “obj/Docker/publish”


    FROM microsoft/aspnetcore:1.0

    ARG source

    WORKDIR /app

    EXPOSE 80

    COPY ${source:-obj/Docker/publish} .

    ENTRYPOINT [“dotnet”, “app.dll”]

    However for me, i don’t actually see that folder or anything in it. Where the “magic” happens is in the volumes section. that essentially moves your code onto the container as a bind mound. this is where your code gets moved onto the container. There are a few other things that happen that aren’t clear to me though because I see a line in the build output where the code gets built/published, but not the actual command that is running.

    This has no real impact when building development images. As Nick explained we get code using bind mount.

    This is used when building images for production use with file docker-compose.ci.build.yml, which outputs to obj/Docker/publish of each solution web project.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.