libgit2
Adding Windows CI, fixing tests on Windows, test robustness
Short story: I got this working
This was a journey. Hear my tale.
What started me on this saga was starting work on sonic pi. It depends on this library. Sonic PI's build instructions imply Rugged is the most fragile part in particular on Windows. Looking here I noticed Rugged does not have any Windows CI. This is important due to how fragile the RubyInstaller and msys2 environments are regarding C extensions. It's no fun doing gem install rugged which fails with no discernible fix from the user. Lets make sure that doesn't happen.
Attempt 1: Github Actions
I tried really, really hard to make this work. Short answer is the Windows images produced by Github are unpredictable and do not have any means of remote access for figuring them out.
Longer answer
The most difficult part of dealing with the Github provided images is getting to the bottom of layers of abstraction. There are definite issues regarding the installation of Ruby on the Windows images. I could not get to the bottom of it.
The recommended way is use the setup-ruby action. This works fine on *nix images. I guess it works fine on Windows images in the fact that the requested version is present. Using it is a matter of frustration.
The most frustrating and baffling thing about these images comes from the unpredictability on which tools run and how performing actions does not apparently affect anything.
For example, the last run where I tried and gave up, I discovered the msys2 system changes from underneath the Rake task that builds the gem and runs tests. You can see this here. Drawing attention to a few lines.
First the build step uses an outdated version of GCC even though earlier in the process I specifically updated the msys2 system which absolutely installed GCC 9.
Further, the actual build step of the gem uses a different tool path in C:\strawberry than the tool which configured the build earlier at C:\hostedtoolcache
This is the point where I gave up. I'm sure it's fixable somehow. There is a 10-15 minute iteration time for understanding these images and there is no remote shell option.
Attempt 2: Appveyor
Appveyor's specialty is it's Windows CI support. I found this true through working with it. I didn't have any troubles with their images. I did have some troubles with Bundler exit non-zero on a harmless warning I worked around. Otherwise it's smooth sailing.
Test breakages
This exposed a few issues with the test suite and potentially with libgit2. I left comments in this PR on where and why I changed things.
Further work
Included is a working appveyor config file. A maintainer of this repo must connect appveyor so it picks up on the reporting status.
I'm curious on the source of the failures I skipped over in the tests. It seems like they're within the libgit2 library and not the C binding code.
I'm also wondering about the open file handles after a test completes. On *nix they're definitely closed, on Windows they still linger until after the suite finishes. I don't feel like it affects day to day usage though.
Looks like linux builds fail for reasons that are not our own. Appears github is transitioning ubuntu repos from ubuntu.com to microsoft.com
https://github.com/libgit2/rugged/runs/346774249#step:4:61