app CI integration testing for Windows support #262
Comments
|
👍 Good idea, until now when making any major changes to the gem or plugins I run it through a VM I have setup with Windows 7 and cygwin. |
|
I'm willing to look this trough. If I'm right the goal is duplication of the travis-flow (or at least test the same things) in AppVeyor? |
|
@mroth is there an existing account for AppVeyor or should is make one of my own testing with my fork? |
|
@nysthee I think I have an account on AppVeyor but nothing is set up on it. It was tied to my GitHub auth anyhow, so I think you'll need to use your own, similar to the Travis model? |
|
What do you mean by similar to the Travis model? |
|
Just that Travis-CI uses GitHub Auth for accounts, so each developer needs their own account. |
|
I will start working on this later this evening. 2015-04-14 21:29 GMT+02:00 Matthew Rothenberg notifications@github.com:
|
|
Looks like the build queues on appveyor are huge. :) |
|
@matthutchinson can you tell a little bit more on the setup of your win 7 vm, issues you encountered, etc... . At the moment lolcommits_test.rb is failing on incorrect file permissions. |
|
hmm, that was a while ago, I may no longer have the vm, will check later when I'm home and see. Can you paste the failure message you get? |
|
|
Just checked and I no longer have the VM 😢 I'll try to set it up again this weekend and see if I run into any issues. |
|
So I spent quite a bit of time yesterday trying to get a Windows 8.1 VM setup and working again with the current lolcommits version (0.5.7). Before even running tests I noticed a bunch of problems on getting the hook/capture to work at all. This commit and this PR. Running the tests now, I've got the same issue as you, so I'll dig into that further. It should be noted that I don't think we've ever had a working test suite running on a Windows machine before (unless @mroth can recall..) |
|
Yeah, we've never even tried the tests there before AFAIK. Great work on the patches @matthutchinson. Just curious , where you able to get it working even omitting the dev-headers versions of Ruby/Imagemagick? I suspect we can skip those steps now that we have migrated from RMagick->RubyMagick, and that could simplify our setup wiki instructions for Windows users substantially. (see #261 for context) |
|
Ignore me, yes you're right we no longer use RMagick, so we can ommit that step altogether. |
|
Whoops, yeah I meant MiniMagick, brain typo. |
|
IMO it is not very useful (as it will never work) to test unix-file permissions on a Windows machine. Ik wi try to work around this particular test. |
|
I Agree.. Interestingly the ImpactFont and the CommandCam permissions DO pass on
So perhaps for this test, we bypass checking the perms for VideoSnap and The next hurdle I came up against was getting Cucumber/Gherkin working on Some posts suggest using only Windows 7 32-bit, others say use Ruby 2.0 or On 21 April 2015 at 08:01, Thomas Nys notifications@github.com wrote:
Matthew Hutchinson |
|
@mroth - i've updated the Windows wiki page a little, there are a few less steps now, but we do still need the Ruby Development Kit installed and configured, since the I think when we move plugins out of the main gem, we can ditch this requirement, and press plugin developers to provide their own tips for Windows compatibility.. https://github.com/mroth/lolcommits/wiki/Installing-on-Windows Also, as it stands v0.5.7 will not work on any version of windows out of the box right now, i'd like to release v0.5.8 tonight (from current master) unless you have any objections? |
|
So after a lot of investigation (and many VM's) I was finally able to get the tests to run (with some success) Gherkin problems mean only Windows 7 (32bit) with Ruby 2.0.0 or 1.9.3 (with RubyDevKit installed) can be used. Currently, gherkin/cucumber fails for Ruby 2.1/2.2 on any Windows box or any 64 bit version of Windows. So here is the output from that run (after skipping those file permission unit tests), not very encouraging, but a least a starting point (33 failed, 113 skipped, 66 passed) ... @nysthee if you have more luck than me, let us know 😄 Ps.. Obviously if we want AppVeyor integration this needs to be passing.. |
|
I will put up a windows 2012 server this weekend (what appveyor uses - x64 only), to dig deeper into this. It doesn't look very encouraging. :D |
|
OK, good luck! @mroth and I were talking and depending on your success, it might be better (for a first step) to only attempt to get a subset of the features passing under Windows. E.g. for the happy path of installing the hook, and capturing a commit. You could use cuke tags (like the @mac-only tag) we currently have, to choose what to run in AppVeyor builds. |
|
I must apologise for the silence but in between my internship, passing exams and a new job I didn't had to much time advancing on this issue. I have a basic appveoyr.yml set up and who basically gives the same output as @matthutchinson's trace above. Also some extra fun I ran into:
Can one of you guys give me a short overview of what exactly needs to pass as a baseline and I will give it a final try. |
|
Sorry, i've been on holiday for the last 2 weeks 🍹 I think the best way forward for now is if you add cuke tags e.g. @win-only to the tests that currently do pass under Windows. Then we'll add another issue here on GitHub to request that ALL tests should pass in Windows. Thanks for all the work you've done so far on Appveyor integration. If its possible can you invite me to the Appveyor project you've created, so I can manage it too? My GitHub username 'matthutchinson' is associated with my account there. Or issue a PR with the relevant Appveyor YAML file. |
|
Feature/appveyor ci #280 contains the yaml file. |
Now that AppVeyor is around, it looks like we can theoretically add Windows continuous integration testing as well (it would be nice if TravisCI supported it, but I don't see that happening soon). This would enhance our ability to make sure builds don't break in Windows over time (since none of the core developers are Windows users) and give us more confidence about supporting without caveat what has historically been for us, if we are honest, not a first-class supported platform.
Ideally we could find someone who is a Windows developer familiar with AppVeyor to take this task on.
The text was updated successfully, but these errors were encountered: