Nix Entry Shell with TTY

A major weak spot right now for Windows Containers is the support for a POSIX shell that supports TTY.

Installing a POSIX-compliant runtime and SHELL statement pointing at an installed shell (bash, sh, zsh) doesn’t offer TTY and stdout is only capable on docker without the -t option. You essentially have to either issue commands with no stdout or not be able to interact.

Additionally, the Windows Subsystem for Linux doesn’t install on containers.

Real world example of why this is important:

Jenkins v2 Swarm can’t light up Windows Container support because executors expect to be able to issue the id and cat commands with TTY with build containers

With AWS bringing Windows Containers into Beta (http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_Windows.html), this seems like a huge win for MS to sell Cloud Lic for Jenkins users.

BTW, Fantastic work on this container digest. We have all been cultivating this stuff since last fall, but good to see some MVPs organizing the public effort.

[StefanScherer]

Thanks @toddpi314, my journey with Windows containers began long before I became a MVP.

I agree, a Jenkins swarm working with Windows Containers would help a lot of people. I wonder why they depend on third-party tools like id and cat as they are not part of vanilla Windows. So here the problem begins as neither Cloudbees nor Microsoft really can help to make it work. I only can suggest to start a discussion about removing that dependency in the Jenkins swarm and use Windows native commands instead. Are there any open issues in the Jenkins / Jenkins swarm repos?

I only know these issues arround MSYS / Cygwin:

• https://github.com/docker/for-win/issues/262
• https://github.com/Alexpux/Cygwin/issues/23
• https://github.com/git-for-windows/git/issues/1007

[StefanScherer]

I’ll close this issue here as it has to be resolve probably in cygwin / mingw. We have collected a lot of links to other issues to follow the progress there.