New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Technical issues implementing Windows support #2104

BanzaiMan opened this Issue Mar 25, 2014 · 21 comments


None yet

BanzaiMan commented Mar 25, 2014


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.


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.)


  • 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).

@BanzaiMan BanzaiMan added this to the Windows support milestone Mar 25, 2014

@BanzaiMan BanzaiMan self-assigned this Mar 25, 2014


This comment has been minimized.


Joshua-Anderson commented Mar 25, 2014


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
- linux
- windows
install_linux: sudo apt-get install openssl -qq
install_windows: Invoke-WebRequest -OutFile c:\python.msi; msiexec /i "c:\python.msi"
script_linux: ./
script_windows: .\travis.ps1

Where step_platform overrides step if the os specified is matched.

You guys are awesome!


This comment has been minimized.


joshk commented Mar 25, 2014

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.


This comment has been minimized.


BanzaiMan commented Mar 26, 2014

I updated the summary a bit.


This comment has been minimized.


sarahhodne commented Mar 26, 2014

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


This comment has been minimized.

schisamo commented Mar 30, 2014

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


This comment has been minimized.

maxlinc commented Mar 31, 2014

@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

This comment has been minimized.


sethvargo commented Mar 31, 2014

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

@BanzaiMan BanzaiMan added the windows label Apr 16, 2014


This comment has been minimized.


BanzaiMan commented Apr 16, 2014

#2172 tracks issues regarding Chef cookbooks.


This comment has been minimized.

maxlinc commented Apr 18, 2014

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.


This comment has been minimized.

maxlinc commented Jun 3, 2014

Note: I'm testing with a 32-bit Windows 8.1 VM, because that's what's available via 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)

@jarib jarib referenced this issue Jul 8, 2014


Windows testing #80

@novocaine novocaine referenced this issue May 26, 2015


Inadequate CI #9

3 of 5 tasks complete

cushon referenced this issue in google/error-prone Jun 4, 2015

Makes ASTHelpersTest pass on Windows.
Windows uses 2-character line separators, but some of the tests in
ASTHelpers encode positions assuming a single-character line separator.
This change makes the tests compute the correct position regardless of
the platform's line separator.

Fixes #336.

This comment has been minimized.

vbauer commented Jun 27, 2015



This comment has been minimized.

tresf commented Aug 23, 2015


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.


  • 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.


This comment has been minimized.

tianon commented Sep 17, 2015

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


This comment has been minimized.

GabrielTK commented Oct 20, 2015

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


This comment has been minimized.


joshk commented Oct 20, 2015

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.


This comment has been minimized.

bradrothenberg commented Apr 23, 2016

any update on windows support?


This comment has been minimized.

fracting commented May 27, 2016

Hi all, welcome to try

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 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.


This comment has been minimized.

levithatcher commented Jun 30, 2016

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


This comment has been minimized.

jayvdb commented Jul 20, 2016 (redirecting to docs...) is timing out for me. 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.


This comment has been minimized.

fracting commented Jul 20, 2016

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:

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 :)


This comment has been minimized.


BanzaiMan commented Jul 20, 2016

If you want to discuss, please use a different venue to do so.

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

@travis-ci travis-ci locked and limited conversation to collaborators Jul 20, 2016

@DrTorte DrTorte added the locked label Apr 2, 2018

@BanzaiMan BanzaiMan closed this Nov 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.