Hi 
Thank you very much for bringing Windows support to Travis CI.
I hope Travis adds support for the popular cross-platform language Ruby, as soon as possible.
Even though ruby has been listed under the packages at https://docs.travis-ci.com/user/reference/windows#pre-installed-packages, the build currently fails with following message:
The language 'ruby' is currently unsupported on the Windows Build Environment.
Hello, there.
Indeed, Ruby 2.5.x is pre-installed via Chocolatey.
The issue here is that, with language: ruby, we compile a script to execute the job, but the script will require some additional tooling that is not yet available on the Windows image yet. We will work on that soon.
@BanzaiMan is it possible to add a Windows build using the preinstalled Ruby to an existing language: ruby Travis configuration? How would I need to adapt?
How can I avoid this? If I don’t specify any lang, it still seems to tell me that error.
Update: I set language: generic but now the build just sits there forever, at least it seems like it might work now?
Has anyone managed to tweak the pre-installed ruby environment so that can compile gems?
I am using ruby2.devkit , but it requires msys2. I would rather not install either given the problems with using msys.
Here is my latest job https://travis-ci.org/jayvdb/coala-bears/jobs/547079066
(All the choco work is hidden under powershell -c "fudge install")
Even then, I cant install travis.rb easily , because it depends on pusher-client which depends on json, which needs -lgmp , and … ouch … I gave up and added gem "pusher-client", "~>0.4.0" to my Gemfile because that version doesnt need the json gem.
Also I found that adding DevKit to the PATH caused everything to run extremely slowly.
See the durations of the commands at https://travis-ci.org/jayvdb/coala-bears/jobs/546698689
I think I have fixed that by adding the following to the beginning of the job to turn off Windows Defender.
- powershell -command 'Set-MpPreference -DisableRealtimeMonitoring $true'
- powershell -command 'Set-MpPreference -DisableArchiveScanning $true'
- powershell -command 'Set-MpPreference -DisableBehaviorMonitoring $true'
I used the following configuration on my Windows build and it completed a bundle install with no errors (I was using the json gem, too):
- os: windows
language: bash
install:
- choco install mingw
- choco install msys2
- ridk.cmd exec pacman -S --noconfirm --needed base-devel mingw-w64-x86_64-toolchain
I guess that is not much different to what ruby2.devkit is doing. I was hoping to avoid msys. I wonder why you needed both the choco package mingw and the msys-pacman package mingw-w64-x86_64-toolchain. I would expect they had similar contents.
What’s the progress on this? Still seeing this issue today. Wish this can be supported soon 
There is a problem: ruby from msys2 package was not configured properly, this config may be valid for cygwin, but not for mingw. Thats why users have to bring together ruby build for windows by rubyinstaller (unpacked by choco) and msys2.
PS we don’t need to use complete base-devel mingw-w64-x86_64-toolchain packages, mingw-w64-x86_64-binutils, mingw-w64-x86_64-crt-git, mingw-w64-x86_64-gcc, make will be enough.
Official travis documentation introduced some strange wunderwaffe export msys2 = ..., it can be replaced by ridk.cmd exec, because we have to deal with rubyinstaller anyway.
- os: windows
arch: amd64
language: bash # using git bash
before_install:
- choco uninstall mingw -y
- choco upgrade msys2 ruby -y
- ridk.cmd exec pacman --sync --noconfirm --needed
mingw-w64-x86_64-binutils
mingw-w64-x86_64-crt-git
mingw-w64-x86_64-gcc
make
After that you can make gem install json with extensions successfully.
Using this simple config I’ve added windows testing for small gem ocg. Please checkout the following successful log.
There is another variant: use mingw-w64-x86_64-ruby instead of ruby from rubyinstaller and i think it will be much better, it will have less issues with library bindings. In this case we may use wunderwaffe from travis.
language: ruby
jobs:
include:
# other jobs
- os: windows
arch: amd64
language: bash # using git bash
before_install:
- |-
choco uninstall -y mingw ruby
choco upgrade -y msys2
export msys2='cmd //C RefreshEnv.cmd '
export msys2+='& set MSYS=winsymlinks:nativestrict '
export msys2+='& C:\\tools\\msys64\\msys2_shell.cmd -defterm -no-start'
export mingw64="$msys2 -mingw64 -full-path -here -c "\"\$@"\" --"
export msys2+=" -msys2 -c "\"\$@"\" --"
$msys2 pacman --sync --noconfirm --needed \
mingw-w64-x86_64-binutils \
mingw-w64-x86_64-crt-git \
mingw-w64-x86_64-gcc \
make \
mingw-w64-x86_64-ruby
before_cache:
- |-
if [ "$TRAVIS_OS_NAME" == "windows" ]; then
# https://unix.stackexchange.com/a/137322/107554
$msys2 exec pacman --sync --clean --noconfirm
fi
cache:
directories:
- ${HOME}/AppData/Local/Temp/chocolatey
- /C/tools
before_install:
- |-
if [ "$TRAVIS_OS_NAME" == "windows" ]; then
$mingw64 gem install bundler
else
gem install bundler
fi
script:
- |-
if [ "$TRAVIS_OS_NAME" == "windows" ]; then
$mingw64 scripts/ci_test.sh
else
scripts/ci_test.sh
fi
This solution works perfect for me. I will try to implement windows support for some gems using such config.
First gem with windows (mingw) support is ocg, you can review travis config and log.
ridk.cmd seems to be distributed with the Ruby installer. The official Travis guidance on use of MSYS2 needs to be as general as possible, so it can’t depend on that (unless ridk.cmd is spun off as an separate project).
Yes, in general use the packages from the “mingw64” repo instead of the “msys2” repo when developing Windows applications. This avoids depending on msys-2.0.dll, which (like Cygwin) is only appropriate for POSIX-targeted programs.
I’ve added windows support for more projects, but I can’t use travis ci anymore, 10000 credits is not enough. I can’t understand travis business model: windows support for ruby projects is not ready yet and marked as experimental, but it is not possible to use it without credits.
Ruby win32 folder has large amount of issues: I’ve found that TCPServer is not thread safe on windows. Now I am moving to appveyor as main ci, I will provide more information on appveyor forums.