Automated testing on Windows via Appveyor #1612

Open
greg-1-anderson opened this Issue Sep 11, 2015 · 30 comments

Projects

None yet

10 participants

@greg-1-anderson
Member

Windows is not tested under CI, and it seems that Windows-related Drush questions do not get good support, either in this queue or on Stack Exchange. This situation has gone on for years.

Roman Paska claims that Drush on Windows is mostly functional, although we still need a little more information about which shells work, what versions of Drush folks are using, etc.

I think that if we could set up CI for Windows Drush, and had a volunteer to do that, and if we had a number of people who could post here and say, "My name is ____, I use Drush on Windows regularly, and I have subscribed to the #drush tag on Drupal Stack Exchange, and will answer Drush on Windows questions there", well, then we'd have a supported platform, and there would be no question about that remaining.

I am somewhat dissatisfied with the current "unsupported but happens to work" state of affairs, though, and would prefer to firmly be in one camp (supported) or the other (support removed).

@jibran
jibran commented Sep 11, 2015

How about this:

  1. Find a good maintainer for windows.
  2. Move the windows hacks out of drush.
  3. Create a new project drush-win for windows only.
@weitzman
Member

I do agree that setting up CI for Windows is the crucial missing piece. Travis is never going to support Windows AFAICT. I've been subscribed to those issues for a long time.

Looks like http://www.appveyor.com/docs/build-configuration is free for open source projects and supports Windows build machines. We could run it in parallel with Travis.

Would be great if someone forked Drush and showed it running on appveyor. All you have to do is sign up on appveyor and add an appveyor.yml to your fork.

@weitzman
Member

I got pretty far along with automated testing on Appveyor. Drush is now installed via Composer. Now we need to get Unish (our test suite) to complete a test run. See https://ci.appveyor.com/project/weitzman/drush/build/1.0.53/job/s70c2tla8fmoppu8 for the current trouble clearing the sandbox and finding drush.bat.

Help appreciated.

@greg-1-anderson
Member

Great progress! From the output, it looks as if the permission denied is caused by Unish trying to remove the sandbox on the first run, before it exists. The code is wrapped in 'file_exists', though, so I don't know what to make of that.

My guess about the drush.bat is it seems that there are too many 's in the PATH -- but I'm not sure about that.

@weitzman
Member

A bit more hacking and the tests are now running. I added a little debugging to solve the Sandbox delete problem but it's not licked yet - https://ci.appveyor.com/project/weitzman/drush/build/1.0.68/job/0ey7dttaiqi75u4w

@weitzman
Member

Tests are proceeding now but Drupal won't install despite my seemimgly providing valid creds. The same creds are working earlier in the process. Once we lick this problem, we need to fix all the quoting, slashes, etc. so that tests pass. I'll be asking for help on this. You can see where we are at by reviewing https://ci.appveyor.com/project/weitzman/drush/build/1.0.92

Sorry for the barrage of commits on appveyor branch. In hindsight, I should have forked before starting this.

@greg-1-anderson
Member

Fantastic. Sorry I haven't had time to help get the test harness set up; I'll help with quoting and escaping issues once we get to that point.

It would be nice if there was someone from the Windows community who could help out here. Not much demand for Drush on Windows, maybe?

@mikeker
Contributor
mikeker commented Oct 7, 2015

I joking call myself the last core contributor on Windows. I realize that's an exaggeration -- there are likely others and I've only contributed to a dozen or so core issues. But I do dev work on Windows and use Drush every single day. I could not live without it! I would hate to see Drush give up on Windows support especially since Drupal and PHP both support Windows as first-class citizens.

As requested, "My name is Mike Keran, I use Drush on Windows regularly, and I have subscribed to the #drush tag on Drupal Stack Exchange, and will (as best I can) answer Drush on Windows questions there." Though I hardly use SE so it may take me a while to get into the swing of things.

Perhaps a better choice is to limit Windows support to the MinGW shell (which comes bundled with Git for Windows, so most dev should have it installed?) Dropping PowerShell support would remove the need for parallel .bat files. At that point, there's just rsync and a couple of oddball GnuWin32 commands and the / vs \ path delimiters to deal with. Or am I over-simplifying things?

Regardless, there is a clear need for CI on Windows as #1595 just broke Drush on Windows. PR coming soon...

@das-peter

I totally agree with mikeker, I created patches for drush years ago since some stuff didn't work on Windows. But back then interest on that work wasn't really there.
Since then I used drush with MinGW on a daily base.

And I found this issue too while looking what was up with the latest drush on Windows because of: #1595 ;)

@weitzman
Member
weitzman commented Oct 8, 2015

@mikeker and @das-peter - thanks so much for chiming in here. We would love your help with Drush on Windows. I would love help getting the Drush test suite to work on AppVeyor, as per this issue. I think your best bet is to fork Drush and hack away in its appveyor branch. You will want to setup a new project on http://www.appveyor.com/ and point it at your fork.

Feel free to ask questions here or in #drush in IRC. When you can get Drush to install itself during the test suite, submit a new PR or announce it here.

@weitzman
Member

@mikeker, @das-peter - Are you guys interested and available in getting Appveyor going? I'm happy to talk you through it by phone if that would avoid some startup headaches.

@mikeker
Contributor
mikeker commented Oct 19, 2015

@weitzman, I think it would be best if I do some basic research and try setting things up before I waste your time on the phone. I'll try to do that this week. I'm new to Drush dev and CI systems in general so there's a bit of a learning curve for me...

@das-peter

@weitzman Thanks for the offer! I've the same perspective as @mikeker and currently I'm veeery busy working on a project while in parallel moving from CH to the US and then to NZ. Thus I've just little time I can spare for all the Drupal stuff :|

@cweagans

Just to clarify here - is the problem Windows itself? Or the crappy "shell" it ships with? Would simply requiring a decent shell be a good solution here? I've heard great things about Babun on Windows, which is just zsh, cygwin, and some other nice things.

I know this has been discussed to death already, but would using something like the Console component or Climate to abstract away all of the weird crap that Windows does be a viable solution here? Composer seems to run well enough on Windows, so I was thinking that maybe the fact that it's a Console app is how they've avoided dealing with Windows headaches.

@mikeker
Contributor
mikeker commented Oct 23, 2015

Just to clarify here - is the problem Windows itself? Or the crappy "shell" it ships with?

A little bit of both, in my opinion. Windows has some oddities (slashes, MAX_PATH, different file permissions) and cmd.exe is completely useless. I think we can work around the oddities as long as we have a relatively *nix-ish environment to work in.

Personally, I use the MinGW shell that ships with Git and a small pile of GnuWin32 utils to give me essentially all I need to minic *nix commands on Windows. I never use cmd.exe.

I think requiring a decent shell (MinGW, perhaps Cygwin -- never used it so I can't speak to it) is a reasonable requirement. I mentioned that earlier in this thread, but didn't hear a reply from the maintainers on that. It could turn off a CLI novice by requiring them to install a bunch of prerequisites...

@cweagans

It could turn off a CLI novice by requiring them to install a bunch of prerequisites...

They'll have to do that anyway at some point, I think. Having a reasonable shell is a requirement for most major open source CLI applications. I don't know of any exceptions to that (which is not to say that there aren't any - just that I don't know about them). It's very seldom that I use Windows for much of anything, but when I do, I use babun just because it's fast and easy to get up and running. That's not to say that Drush should require Babun, per se - just that it might be a good thing to recommend in the installation docs for Windows for people that doesn't know/want to know how to configure some other shell, or even how to choose something different. Better to just recommend something that is known to work in a lot of configurations.

@mikeker
Contributor
mikeker commented Oct 24, 2015

I say this having never tried Babun -- though I'm off to read up on it right now... :)

Better to just recommend something that is known to work in a lot of configurations.

In my opinion that would be MinGW, the shell that comes with Git (witth one minor tweak that we can document -- bsdtar vs. tar). If we can assume that CLI novices are biting the CLI bullet, I believe we can assume they'll be biting the Git bullet as well. The vast majority of Drupal dev work is centered on Git so we can safely assume that they have (or will soon have) Git installed if they're making the dive into the CLI.

@kenorb
Contributor
kenorb commented Nov 10, 2015

drush works on Windows fine (with Git shell installed), however the only problem which I've seen is that by default it's trying to run drush.launcher, which is doesn't work properly, so the workarounds are:

So there are few minor tweaks to work on.

Writing appveyor tests is actually good idea (+ additional dependencies installed via choco).

@hansfn
Contributor
hansfn commented Nov 15, 2015

"My name is hansfn, I use Drush on Windows regularly, and I have subscribed to the #drush tag on Drupal Stack Exchange, and will answer Drush on Windows questions there."

Regarding the shell: I have used Mingw in various packaging for years, but I think we should support Powershell as the default/preferred shell on Windows. ("GitHub Desktop" or "GitHub for Windows" does exactly that for Git with Mingw (Git Bash) as an optional shell.) Let's just forget about Cmd.

So what can I do to help you guys?

@weitzman
Member

Thanks @hansfn. From my perspective, the best next step is for someone to fork drush's appveyor branch and get the tests passing (or at least completing) on Appveyor. Read up on this issue for details. I'm happy to help when you guys get stuck.

@weitzman weitzman changed the title from Should drush continue to support the Windows platform? to Automated testing on Windows via Appveyor Dec 22, 2015
@christopher-hopper
Contributor

@greg-1-anderson,
On Drush for Windows there is some great news from Microsoft:

Windows provides developers with a familiar Bash environment.

Windows is running Ubuntu user-mode binaries provided by Canonical. This means the command line utilities are the same as those that run within a native Ubuntu environment.

You can now install a bash command-line on Windows, that runs in an Ubuntu-like environment, which is fully supported by both Microsoft and Canonical.

I've been using Drush on Windows for many years by installing Cygwin with some packages (like PHP) provided by Cygwin Ports. This new development at Microsoft changes the game however.

As a first step, I'd like to update the Install Alternatives documentation to reflect this new development from Microsoft.

@christopher-hopper
Contributor

Okay, I've been reading up on http://www.appveyor.com/ and the progress so far in running tests.

I'll have a crack at getting something started using the new Windows Subsystem for Linux and post back here if I get something working.

@weitzman
Member
weitzman commented May 4, 2016

@christopher-hopper - that would be a huge service for many people. Thanks!

@hansfn
Contributor
hansfn commented May 5, 2016

Just a minor remark: It seems "Windows Subsystem for Linux" only is available for recent versions of Windows 10. Some of us are still stuck on Windows 7 :-(

@christopher-hopper
Contributor

For Windows 7 I'd stick with Cygwin and Cygwin Ports as the best experience I've ever achieved with Drush. If I can get the WSL bash tests running first, then maybe I'll look at how to automate tests and document an install using Cygwin.

As for the Windows Cmd.exe, that's just not worth the effort anymore.

@Benosika
Benosika commented May 25, 2016 edited

Moved to:

#2196

@weitzman
Member

Still looking for a hero to pick up this effort.

@weitzman weitzman referenced this issue Aug 19, 2016
Merged

Skip the launcher when using Windows. #2312

4 of 4 tasks complete
@weitzman
Member

Good news!

I finished a bunch of Windows compatibility work on the Finder which will make life much better. See #2312.

We are now successfully running all tests at Appveyor. There are still plenty of fails but many need fixes in tests, not in the Drush code. Please open PRs against Drush's appveyor branch for fixing these. Hopefully Appveyor wlll test those PRs.

@greg-1-anderson
Member

Just a note -- The various consolidation projects (robo, annotated-command, output-formatters and log) are now completely tested in Appveryor, so there shouldn't be any further failures due to deficiencies in these upstreams.

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