For us it would be very helpful to support Windows agents.
We mainly use the phabricator for devops tasks in a microsoft environment. So we develop several powershell frameworks we need to test before deploying them.

Microsoft is providing a way forward here with their implementation of OpenSSH.

There's still a few (minor) things that are needed from the Phabricator upstream to make things work; mainly changing a few of the shell commands that "Lease Working Copy" runs, but other than that, everything works with the current implementation.

I'm going to rename this task to a more general "Support Windows agents in Drydock" to reflect the state of the world today.

I just wanted to add a vote of support for this (following up from here) - for Haskell.org Windows is one of the "Tier-1" platforms that we ship binaries for, and having continuous integration is exceedingly useful for a number of reasons.

Particularly for GHC, which has very deep integration with the underlying operating system (with lots of C, some assembly code, major build systems etc), unknowing developers can easily break things. In practice this is really poor form since our Windows developers are a relative minority, while we have a dis-proportionally large number of users. So having Windows support for Harbormaster would substantially improve the status quo here, and help out our Windows users/developers more than most.

Realistically, Windows has historically been very hostile to all sorts of automation like this, but Microsoft's commitment to OpenSSH is still ongoing, which is a very good sign IMO. I still think the jury is a bit out (they haven't added it to Windows Server or anything, of course), so I would not suggest that this be upstreamed immediately.

Alternatively, in the same vein that Phabricator now has CircleCI support, it may be worth investigating some form of integration with Appveyor, which is being more and more widely used on GitHub, etc as "Travis-CI for Windows". This is much more web 2.0, and SaaS-based, so maybe less overall problematic.

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

The reason it hasn't been added to Windows Server yet is that none of their releases are production ready (see: https://github.com/PowerShell/Win32-OpenSSH/releases).

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Yeah, Appveyor only supports one concurrent build, but that's *more* than OK for us now, at least. Any form of CI on master and our STABLE branches, at least, is better than no CI for Windows.

Also, for our use case (a public repo where anyone can submit a patch) until Drydock can be enhanced to lease hosts in more dynamic ways, our plans aren't to enable it for Differential patches. Slow integration for commited things is fine, in this case. We have the same policy for OS X - those systems don't have any real good container/lockdown functionality IME, so to CI patches on them, we really need ones that can acceptably run 'risky' patches. Ideally, we would just create a new VM from a fresh set of images on every patch (adding a small overhead), so temporarily messing with any one given machine doesn't do anything bad. On Linux, at least, we can today use containers and do a significant amount of hardening on it.

Either that, or obviously change handoff needs to be improved somehow so that we can run 'risky' build bots against certain, approved patches after they have been accepted. Anyway, getting a bit off topic.

The reason it hasn't been added to Windows Server yet is that none of their releases are production ready (see: https://github.com/PowerShell/Win32-OpenSSH/releases).

Interesting. Have they said anywhere that they plan on trying to ship this with Windows Server? I mean, I remember the original announcement but I was pretty sure they said something like "Oh, it works but, we make no promises about what the future of this is". I totally haven't paid attention here.

In T10203#185542, @thoughtpolice wrote:

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

Yeah, Appveyor only supports one concurrent build, but that's *more* than OK for us now, at least. Any form of CI on master and our STABLE branches, at least, is better than no CI for Windows.

Oh for sure, it'll work fine for some use cases. But for our scenario we're deploying like 70 jobs in parallel in Windows, so we really need the parallelism that Harbormaster / Drydock provides (and every other providers seems to want to charge for).

Also, for our use case (a public repo where anyone can submit a patch) until Drydock can be enhanced to lease hosts in more dynamic ways, our plans aren't to enable it for Differential patches. Slow integration for commited things is fine, in this case. We have the same policy for OS X - those systems don't have any real good container/lockdown functionality IME, so to CI patches on them, we really need ones that can acceptably run 'risky' patches. Ideally, we would just create a new VM from a fresh set of images on every patch (adding a small overhead), so temporarily messing with any one given machine doesn't do anything bad. On Linux, at least, we can today use containers and do a significant amount of hardening on it.

Yeah, I wrote some EC2 and libvirt plugins for Drydock ages ago, but the API is still unstable so I've abandoned the idea of maintaining them.

The reason it hasn't been added to Windows Server yet is that none of their releases are production ready (see: https://github.com/PowerShell/Win32-OpenSSH/releases).

Interesting. Have they said anywhere that they plan on trying to ship this with Windows Server? I mean, I remember the original announcement but I was pretty sure they said something like "Oh, it works but, we make no promises about what the future of this is". I totally haven't paid attention here.

Sorry, that was badly worded (I re-wrote it like 20 times).

Microsoft is unlikely to commit to shipping it out-of-the-box in anything until they get past the "non-production ready" stage. Once they've marked it as production ready, it might be built into one or more of their services later down the track. My bet at the moment is that it'll be integrated into PowerShell (and thus all Windows versions), but we'd need to wait until after the pre-release stage before we can expect Microsoft to announce anything.

That said, when it does get the production ready stage, it should be considered stable enough for adoption regardless of whether it's built-in. Microsoft has pretty high standards for what they declare production ready (much higher than most open source projects).

Even now, the response rate on the project is pretty good; I've been reporting bugs as I've found them and gotten responses / fixes within a few working days. So it's pretty usable even for those of us that are will to use some prerelease software.

Right now I have a few minor patches (those detailed above) to get Drydock talking to it properly, but once https://github.com/PowerShell/Win32-OpenSSH/issues/243 is fixed in the next version, I plan on providing an executable shim you can install on a Windows machine that transforms the UNIX-style commands that Drydock provides into a format suitable for Windows execution. This means you'd be able to be performing builds on Windows without any explicit upstream Phabricator support for it.

I should add that their plans for mid-2016 is to integrate all of this Windows OpenSSH support into the OpenSSH upstream repository, which is likely to be the time that Microsoft declares it production ready.