Technical issues implementing Windows support

[BanzaiMan]

Note

We recognize that there is an overwhelming demand for Windows support on Travis CI.

This ticket aims to keep track of the technical issues involved in realizing it. As such, please refrain from commenting with just 👍 without any technical input. We will remove such comments on this ticket.

Scope

Our initial focus is to run Travis CI builds on Windows workers.

1. Boot a Windows VM
2. Compile a build script similar to the one as we do now in Linux and OS X
3. Allow comparable customizations by the user (auxiliary services, etc.)

Things not covered in scope (at least initially)

1. Multi-OS support
2. Multi-Windows-version support (This might be a reasonable feature, but I do not yet know difficult it would be.)

Tasks

• Implement ability to boot a Windows VM (on Azure primarily, and other cloud providers possibly)
• Add to travis-build the ability to generate a build script for Windows host. For this, we believe PowerShell is the most reasonable choice as the language.
• Adapt travis-cookbooks to run on Windows host. (Tangentially, investigate test-kitchen for testing our cookbooks).

[Joshua-Anderson]

❤️

I was wondering if you were going to allow developers to specify different actions for the env, script and installstages of the build based on platform. Since most programs require a completely different set of steps to build on windows, I think it would be awesome of Travis to support this as well (for example: allow developers to call a power shell script on windows instead of a shell script) perhaps like this:

language: cpp
os: 
- linux
- windows
install_linux: sudo apt-get install openssl -qq
install_windows: Invoke-WebRequest https://www.python.org/ftp/python/3.4.0/python-3.4.0.amd64.msi -OutFile c:\python.msi; msiexec /i "c:\python.msi"
script_linux: ./travis.sh
script_windows: .\travis.ps1

Where step_platform overrides step if the os specified is matched.

You guys are awesome!

[joshk]

That is the general idea, but not like that.

Instead each job can be specified, at least for V1.

That said, multi os testing won't be enabled by default for V1.

We have a lots to do before we get there, we first need to focus on the tasks Hiro has specified before we can broaden our scope.

[BanzaiMan]

I updated the summary a bit.

[henrikhodne]

I opened a new ticket to discuss how to add multi-platform cookbooks: #2110.

[schisamo]

If y'all need some help on the Chef + Azure bits of this effort be sure to reach out to us (CHEF). We would definitely like to leverage Travis for more of our Windows testing. /cc @adamedx @sethvargo

[maxlinc]

@schisamo @sethvargo @adamedx - glad you guys are watching this. I was thinking about reaching out to you after seeing the comment that kitchen-vagrant doesn't support windows yet; but it is a priority.

I have ideas about how to workaround or use experimental windows (winrm) support for vagrant and serverspec, but I don't know if the kitchen-vagrant limitations are something I can work around.

Would love your thoughts on whether it's better to:

• Attempt to use the current test-kitchen (working around windows issues)
• Wait a bit and then use test-kitchen w/ experimental windows support
• Don't use test-kitchen (for windows) at this point; go w/ pure vagrant and serverspec or some other test stack

[sethvargo]

We should bring in @mitchellh. I know Windows support is on his radar.

[BanzaiMan]

#2172 tracks issues regarding Chef cookbooks.

[maxlinc]

I created a proposal, #2191, for how the travis-build/travis-worker project can start testing on Windows even before we have a solution for travis-cookbooks/travis-images.

[maxlinc]

Note: I'm testing with a 32-bit Windows 8.1 VM, because that's what's available via modern.ie for VirtualBox on Mac. The image available from msopentech is Windows Server 2012 R2 Datacenter. I'm not sure if it's 32 or 64-bit. It's also Hyper-V only, so doesn't help w/ VirtualBox.

Any planned target for the actual boxes? I'm guessing 64-bit Windows Server 2012 R2 Datacenter.

I'm going to have to fork some chef cookbooks and chocolatey packages to fix 32-bit support, even if the prod boxes will be 64-bit. (I'd switch to 64-bit myself, but the lack of available baseboxes makes it a non-trivial task)

[vbauer]

👍

[tresf]

👍

Perhaps one obstacle worth mentioning for Windows build support is deciding which package managers to support caching for. I'm not sure how common cross-compilation support on Windows is, but our project (LMMS) has cmake recipes that make this possible and our dependency listing is on the large size (~1GB) so we may be a good use case to help test Windows building, once available.

From the C++ side of the dependency fence, we (LMMS) are putting some time into supporting msys2 due to a hard-dependency on mingw-w64 (not to be confused with mingw32) for compilation and unfortunately for us, the classic solutions -- cygwin, classic msys and mingw32 -- simply don't suit our needs.

Thoughts

• Msys2's port of pacman currently relies on sourceforge mirrors (much like MacPorts does) for fulfilling dependencies. Unlike MacPorts -- which seems to be able to recover when a package mirror is broken or slow -- Msys2 pacman can't recover, happening about 10% of the time (likely an upstream bug). Retrying the command fixes things, but this could be something where travis mirror caching could really help. Off topic? Perhaps, but it will most likely throw false-positives in regards to build failures which I know happens now if caching isn't enabled and an upstream repo is unavailable.
• Another obstacle may be escalating privileges to circumvent UAC. One of our work-arounds in Msys2 for some mismatched POSIX vs. Windows path names is to create some symbolic links in C:\, which requires account escalation, but AFAIK, Windows lacks the concept of su or sudo from a terminal (or PowerShell) although Server 2012 Core must have an equivalent to UAC, since it's a headless environment.

Anyway... today our .travis.yml doesn't contain the logic necessary to fire Windows builds just yet (naturally, since it hasn't been invented 😄 ), but I at least wanted to chime in that our team would be happy to offer some testing if and when this feature becomes available.

[tianon]

Does the new GCE architecture help at all with implementation of this? 😄

[GabrielTK]

I Think I can help in these 3 steps, using lots of powershell and .NET. Contact me via e-mail: enricorocha1@hotmail.com

[joshk]

I am interested in starting a Slack channel where we can discuss this.

I think we can break this down further and make it easier.

Please email me at josh at travis-ci dot com if you are interested in joining the chat.

[bradrothenberg]

any update on windows support?

[fracting]

Hi all, welcome to try https://www.tea-ci.org

Tea CI is a continuous integration service for Windows applications, free for open source developers.
Tea CI runs on Linux + Docker + Drone + Wine.

Note that this is only an alpha release, any risk is possible, read https://sourceforge.net/p/msys2/mailman/message/35107680/ for some background information.

Any feedback is great appreciated.

To Travis CI team:
I'm Qian Hong, a Wine contributor and a Msys2 contributor, also the creator of Tea CI. More than one year ago, I wrote an email to Travis CI support for volunteering to provide a CI solution for Windows build with Wine, but my suggestion did not convinced Travis CI team at that time, so I created my own Tea CI service to serve open source developers. If any time Travis CI team would like to support Windows build using Wine, I'm always here to help, I'm glad to be contacted either publicly or privately.

[levithatcher]

Any update for Windows support? We've been loving travis-ci and have been huge evangelists for it!

[jayvdb]

https://www.tea-ci.org (redirecting to docs...) is timing out for me. https://tea-ci.org/ is working, but is a little slow.

But if tea-ci is only Wine, that can be done fairly easily on Travis by installing wine on a standard image, or rolling your own image.

[fracting]

But if tea-ci is only Wine, that can be done fairly easily on Travis by installing wine on a standard image, or rolling your own image.

Initially we began from trying Wine on Travis CI, but it ends up with some corner cases which can't be controlled by end user but affects Wine functionality, for example the aufs filesystem using by Travis CI breaks Wine extent attributes: https://bugs.wine-staging.com/show_bug.cgi?id=403

That's why we end up with an open source environment with fully control.

I'm always happy to see more users using Wine, if anyone has universal solution for Wine on Travis CI please share! If Travis CI works great with Wine, I'm glad to help Tea CI users transfer to Travis CI, otherwise I'm glad to receive any contribution / volunteer to Tea CI :)

[BanzaiMan]

If you want to discuss tea-ci.org, please use a different venue to do so.

I am locking this one until we have other issues to discuss.