Teamcity Agent in Docker for Windows

I'm trying to get a Teamcity agent up and running in Docker-EE Basic on Windows Server 2016 (version 14393.2125). The agent does show up nicely in the Teamcity server, and also automatically upgrades. However, the moment I try to run a build that pulls data from Git I'm getting an error saying stderr: fatal: Invalid path '/ContainerMappedDirectories': No such file or directory. I ran this error through Google and found both a long-ish thread on https://www.bountysource.com/issues/40368769-git-clone-does-not-work-in-windows-docker-container-in-mounted-host-volume-folder talking about the issue, and a link to a slide (http://stefanscherer.github.io/windows-docker-workshop/#104) which is supposed to have a solution.

We have modified the Docker image slightly using this Dockerfile to install requirements for build older .NET projects (non-.NET Core):

FROM jetbrains/teamcity-agent:2017.2.3-windowsservercore

SHELL ["powershell"]

# Install Windows features to enable ASP.NET building
RUN Install-WindowsFeature NET-Framework-45-ASPNET ; \
Install-WindowsFeature Web-Asp-Net45

# Install Microsoft Build Tools 2013, 2015 and 2017
RUN Invoke-WebRequest "https://download.microsoft.com/download/9/B/B/9BB1309E-1A8F-4A47-A6C5-ECF76672A3B3/BuildTools_Full.exe" -OutFile BuildTools_2013.exe ; \
Start-Process BuildTools_2013.exe -Wait -ArgumentList /Silent, /Full ; \
Remove-Item -Force BuildTools_2013.exe ; \
Invoke-WebRequest "https://download.microsoft.com/download/E/E/D/EEDF18A8-4AED-4CE0-BEBE-70A83094FC5A/BuildTools_Full.exe" -OutFile BuildTools_2015.exe ; \
Start-Process BuildTools_2015.exe -Wait -ArgumentList /Silent, /Full ; \
Remove-Item -Force BuildTools_2015.exe ; \
Invoke-WebRequest "https://download.visualstudio.microsoft.com/download/pr/100285490/e64d79b40219aea618ce2fe10ebd5f0d/vs_BuildTools.exe" -OutFile BuildTools_2017.exe ; \
Start-Process BuildTools_2017.exe -Wait -ArgumentList --add, Microsoft.VisualStudio.Workload.MSBuildTools, --quiet ; \
Remove-Item -Force BuildTools_2017.exe

# Add Visual Studio targets
COPY ["./VisualStudio", "C:/Program Files (x86)/MSBuild/Microsoft/VisualStudio/"]

Is there any known solution to this?

0
6 comments

Hi Patrick,

Does the same happen with the default image? Or only with your custom modified one?

0
Avatar
Permanently deleted user

Hello Denis,

The default image doesn't seem to work either. We are running it via docker-compose like this:

version: '3'
services:
agent2:
image: jetbrains/teamcity-agent:2017.2.3-windowsservercore
restart: unless-stopped
environment:
- SERVER_URL="https://10.110.0.95/"
- AGENT_NAME="Agent 4 - Default image"
volumes:
- ./agents/agent 4/conf:C:/BuildAgent/conf
- ./agents/agent 4/work:C:/BuildAgent/work
- ./agents/agent 4/logs:C:/BuildAgent/logs
The exact error we are getting is:
[15:16:25] : [VCS Root: GitRoot] Update checkout directory (C:\BuildAgent\work\4f144d410fd981ea)
[15:16:25] : [Update checkout directory (C:\BuildAgent\work\4f144d410fd981ea)] The .git directory is missing in 'C:\BuildAgent\work\4f144d410fd981ea'. Running 'git init'...
[15:16:25] : [Update checkout directory (C:\BuildAgent\work\4f144d410fd981ea)] git.exe init
[15:16:25]i: [Update checkout directory (C:\BuildAgent\work\4f144d410fd981ea)] fatal: Invalid path '/ContainerMappedDirectories': No such file or directory
[15:16:25]E: [Updating sources] Failed to perform checkout on agent: 'git.exe init' command failed.
exit code: 128
stderr: fatal: Invalid path '/ContainerMappedDirectories': No such file or directory

This is, of course, after it has spent some time receiving objects and deltas. I find it hard to believe I am the first one to encounter this, especially as it happens on both the -windowsservercore and -nanoserver builds.

0

Hello Patrick,

Thanks for pointing this issue, it looks like MSFT plans to fix it in the coming Windows 1803 containers release: https://github.com/git-for-windows/git/issues/1007#issuecomment-356736501

Thus any existing git for windows clients will fail with that error, so workaround is do not add "C:/BuildAgent/work" as a volume.

> The agent does show up nicely in the Teamcity server, and also automatically upgrades

To prevent TeamCity build agent upgrade on each container start you need to add the following volumes:

* C:/BuildAgent/plugins

* C:/BuildAgent/system

* C:/BuildAgent/tools

0

Hey guys, any updates here?

@Dmitry when I add the following lines to docker:

    services:
      teamcity-cyndaquil:
        image: jetbrains/teamcity-agent:latest-windowsservercore
        volumes:
          - ./teamcity-cyndaquil/conf:C:/BuildAgent/conf
#...
          - ./teamcity-cyndaquil/plugins:C:/BuildAgent/plugins
          - ./teamcity-cyndaquil/system:C:/BuildAgent/system
          - ./teamcity-cyndaquil/tools:C:/BuildAgent/tools

 

I end up with

ERROR: for administrator_teamcity-cyndaquil_1  Cannot start service teamcity-cyndaquil: container c2ff83922e4e950ce329222b7db4b57d7ee9d778d62f6bcc8
b482c894d729b5e encountered an error during CreateContainer: failure in a Windows system call: The directory is not empty. (0x91) ...

which is because docker doesnt support "merging" existing folders onto the host OS, so how can i pre-empt this?

 

also, I'm getting the same git.exe errors:

Failed to perform checkout on agent: '"C:/Program Files/Git/cmd/git.exe" init' command failed. exit code: 128 stderr: fatal: Invalid path '/ContainerMappedDirectories': No such file or directory 

according to the thread you linked to, a fixed snap-shot is up, any chance we can get a rebuild of the docker image with the new git.exe?

0

Hi Geoff,

I'm afraid that the last images don't include the patches yet. We hope to publish today 2018.1.1 along with images, and those should include the windows release with the patch, so I'd like to ask you to give it a shot once we publish them and it should get better.

Before following up on the other issues I'd wait until the new images are up, they are quite possibly related.

PD: Your agent's name is brilliant, hope it doesn't burst into flames.

0

A quick follow up, we have had to move the publish date to next week, hopefully monday due to a couple last minute QA issues we detected.

0

Please sign in to leave a comment.