Make the tests work on Windows #213

Merged
merged 5 commits into from Mar 10, 2015

Projects

None yet

2 participants

@pfmoore
Contributor
pfmoore commented Mar 5, 2015

Getting the tests to work on Windows wasn't as hard as expected. Mostly by skipping the ones that weren't obvious :-) I may have broken some of the tests on Unix, posting this PR for Travis to check...

@pfmoore
Contributor
pfmoore commented Mar 5, 2015

Looks like there is a problem with me renaming (on Windows) the "err" script to "err.py". In doing so, I guess the execute bit got lost as Windows doesn't have one of them. A "simple" solution would be for someone to fix this on Unix and leave it at that, but doing so might mean that if a Windows user ever changed that file in future, it would get broken again. I'll try a more robust fix that runs the command using the Python interpreter directly.

@pfmoore
Contributor
pfmoore commented Mar 5, 2015

@bitprophet That was a lot easier than I expected. This PR patches up the tests to make them work on Windows (mostly by skipping the pty-related ones, plus a few small tweaks to commands that don't work the same on Windows) and adds support for running on Appveyor.

To enable Appveyor testing all you need to do is sign up for the Appveyor free plan using your github account, then do "Add project", select github and pick this project. Once added, builds will run automatically.

Appveyor is phenomenally slow, because the free plan has pretty limited resources (mostly it's just that you wait for workers for a long time - when the tests finally run they run about as fast as Travis). I'm testing Python 2.7, 3.3 and 3.4 (32 and 64 bit) as those are the ones Appveyor has installed by default. You can add more just by downloading and installing the extra versions of Python yourself, but IMO it's not worth the effort.

Actually, Appveyor has found a bug for Windows - Python 3.3 chokes trying to read /etc/invoke which doesn't exist (looks like some issue in core python importlib, which has presumably been fixed in 3.4). At some point, invoke should get its config from a more appropriate location on Windows but I'll see if I can find a short-term patch in the meantime.

@pfmoore
Contributor
pfmoore commented Mar 5, 2015

Actually, the "Python 3.3 bug" seems to be that you're using imp.load_source in invoke/config.py, which was removed in 3.3. I'm somewhat baffled as to why it still works on Travis :-(

I'll raise a separate issue for this - its not something that should be bundled in with this PR...

@bitprophet bitprophet and 1 other commented on an outdated diff Mar 5, 2015
tests/runner.py
@@ -54,7 +58,11 @@ def nonzero_return_code_for_failures(self):
result = run("false", warn=True)
eq_(result.exited, 1)
result = run("goobypls", warn=True, hide='both')
- eq_(result.exited, 127)
+ if WINDOWS:
+ # Windows doesn't give a 127 error for "unknown command"
+ assert result.exited != 0
@bitprophet
bitprophet Mar 5, 2015 Member

Does the actual numeric result vary or something?

@pfmoore
pfmoore Mar 5, 2015 Contributor

I think it's just 1, but I couldn't be sure it's the same everywhere (Windows doesn't have a tradition of well-defined "system-level" exit codes like this). So I just left it as non-zero as a safe option. I'm happy enough to say "equals 1" and fix it later if that's too specific.

@bitprophet
bitprophet Mar 9, 2015 Member

Don't care super hard, was just curious, thanks.

@bitprophet bitprophet and 1 other commented on an outdated diff Mar 5, 2015
tests/runner.py
def pty_defaults_to_off(self):
eq_(run("true").pty, False)
def complex_nesting_doesnt_break(self):
+ # Not sure how to make this work on Windows
+ if WINDOWS:
+ skip()
@bitprophet
bitprophet Mar 5, 2015 Member

Might make sense to turn this into a decorator like e.g. @posix_only or @no_windows? since it's used a bunch.

Could potentially also use Nose's built in tagging stuff and then run the tests with a "skip windows tag" option, though I've never used that nor do I know offhand whether spec would break it as-is.

Either way it'd be a decorator tho.

@pfmoore
pfmoore Mar 5, 2015 Contributor

Yeah, a decorator makes sense. Presumably tests/_utils.py would be a reasonable place to put it?

@pfmoore
Contributor
pfmoore commented Mar 5, 2015

OK, this is now ready to go. The tests fail on Windows without #215 but that's an independent issue hence the separate PR.

@bitprophet
Member

Confirmed tests still run OK on my end. Thanks!

EDIT: Shoot, wrong ticket, that was 215. El oh el. However, the tests for this branch ALSO pass so yay for that.

@bitprophet bitprophet merged commit 1bd901d into pyinvoke:master Mar 10, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bitprophet bitprophet added a commit that referenced this pull request Mar 10, 2015
@bitprophet bitprophet Changelog re #215, re #213, re #214 89e147e
@bitprophet
Member

FTR I just set up AppVeyor under my own (Github) account. Seems to be running now, will see how it completes (I just did some big ol refactoring, so...).

Obviously, in some cases where the Windows breakage isn't obvious/trivial, I won't be able/willing to actually dig into stuff - but at least now I'll know, and ostensibly Windows users will be able to view the build status so you know you're not off your rocker if things are breaking on your end.

@pfmoore
Contributor
pfmoore commented Mar 11, 2015

@bitprophet if there are windows issues, feel free to ping me and I'll see what I can do to assist.

@bitprophet
Member

Of course, appreciated. Just saw aforementioned refactor did break things in one test, already applied fix. Fun times. EDIT: also, you weren't kidding about slow :D good thing this is all semi-optional for me, I can just ignore it and check again later.

@bitprophet bitprophet referenced this pull request in paramiko/paramiko Apr 1, 2015
Open

Implement Windows CI with Appveyor #505

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