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.

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.

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.

You must include reproduction steps when filing bug reports. See Contributing Bug Reports.

Your answer is right here:

After further investigation, we might just be able to tell users to set the "Name" field of the key that they want to use for production bastion access. I hadn't previously realised that this field was editable by clicking on the key in the "SSH Public Keys" pane.

The constants aren't interchangeable no; one is a constant for the Harbormaster artifact type and one is a constant for a Drydock resource type. They're two different sets of types.

Just FYI, but on this install there's some weird rendering going on:

I managed to work around this for now by just doing this manually:

Just got this 3 times in a row again.

(requesting changes because the proc_open is clearly wrong)

It's unclear to me the value of this change if it doesn't handle CMD escaping.

So I managed to resolve this eventually. It looks like the underlying cause of all the problems was that the SSH daemon on the build server itself had got into a weird state where it would accept connections, but not initiate an actual SSH session.

So I manually set the resource to a destroyed status, cleared out drydock_command and saw Drydock attempt to start allocating a new resource. However, now I'm getting:

In the case of Projects (v3) it looks like you used it to bucket things based on who was assigned, but this doesn't seem like a very feasible / useful thing to do until T5474 is done, because otherwise it's a very manual process.

It feels like the more formal / correct way to do it I guess? Like, I'd expect in future that reporting would occur over milestones in a project, and not columns on a workboard, because the columns don't have any relation between them (as opposed to milestones which explicitly have a "next" and "previous" milestone).

As far as I understood it, milestones being projects were an implementation detail, because @epriestley didn't want to have two separate structures for sub-projects and milestones.

(I realise that milestones are projects, but I simplified my response to distinguish between the parent project and the milestone that is under that parent project)

No, I'm suggesting that when you click the "Project (Milestone)" tag in the UI, it should take you to the project's workboard.

Where is this configurable?

As someone who regularly uses Arcanist on Windows, I can't say I've seen this issue. You should try placing Arcanist in a writable directory, like C:\Tools\Arcanist. Installing it into "Program Files" is probably not ideal, as that's not a writable location.

Yeah, this is a known bug with aborting builds. It doesn't actually functionally impact anything (you can still restart the builds later, etc.)

In T11153#180624, @epriestley wrote:

You can determine both of these from the harbormaster step dependency tree.

Today, yes, but not if the tree includes custom build steps which allocate resources or if we add "if <condition>, run <another build plan>" or "foreach <item> in <artifact>, run <another build plan with 'item' as an input>". I think these capabilities are probably more interesting than being able to automatically count how many resources a build needs is.

We could do this when a plan is predictable, although an automatic lock acquisition scheme could fail in cases where an explicit one would succeed: for example, when a plan is edited, we may change discovered lock order from "A, B" to "B, A", and builds on the new version of the plan could deadlock with currently-executing builds. If both versions of the plan acquire locks explicitly builds will be able to survive edits.

You don't really need an explicit release lease to solve this problem. Nor do you need an explicit locking system for resources. You can determine both of these from the harbormaster step dependency tree.

Local Version Bitnami Phabricator 20160523-0

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

This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).

Extensions are a really advanced feature, and you will get almost no support from upstream here if you have them installed. Or another way, anyone who is installing extensions should know Phabricator well enough to know how to fix this issue manually (hand editing local.json).

I was kind of expecting that 'cluster.read-only' would be a database configuration value, not a local configuration value. Otherwise you need to update all nodes in the cluster instead of just setting the flag in the DB. My expectation when the cluster DB is read-only is that only the following operations work:

@aristedes It means projects and subscribers of the commit. For example, you can add those projects here:

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

@kaendfinger This task is about arc patch. arc land is separate, and I don't believe there's anything Arcanist can do (other than not signing at all) because it must mutate the commits in order to land them. Since you don't have the original author's private key when landing, it can't be signed correctly when you do arc land.

You can talk to Passphrase over Conduit; you need to give credentials access by clicking the "Allow Conduit Access" action.

Yeah I think assignee is an important piece of information, but created seems not that important? And like, in terms of focusing a user's attention, the gutter feels like "this is the second most important thing to title". Like having the avatar of the user who created it doesn't feel like very useful information.

Personally I'm not really sold on the gutter text. It forces everything else down for what could just be positioned at the top of the sidebar?

FYI we'd mainly be placing devops engineers in the "allow push any branches" project group, so that in the case where we need to hotfix production, authorized users can create a branch in the remote to create a release from it.

I'd expect there to be either per-repository rules (like "Tracking Branches" for repositories right now), or Herald-based rules "on branch hook, convert to Differential Revision action" that would allow Phabricator to determine whether a branch is allowed in the remote or not.

In T5000#176433, @epriestley wrote:

non-master branches in the repository would be Differential Revisions

I think the closest match for this is T10691 (GitHub-like forking). I'd plan to implement forking very similarly to GitHub.

I don't plan to ever encourage users to create un-namespaced personal branches in the remote because I believe this process doesn't scale well to a large number of users. Much of the value of forking in my mind is giving users who want to do this (particularly, under the "git push = save changes" mode of thinking) a namespaced place to do it.

To me, I imagined this task would be supporting something rather like:

Try disabling php-apcu and other performance related extensions. Some of them (like APC) are known to cause segfaults or other issues, so unless you actually need to have them installed, I'd suggest disabling them and see if the issue still occurs.

This sounds like an issue with either git clone or the SSH client installed on the build machine itself, and not Phabricator. I don't believe upstream offers support for configuring build agents (they don't offer support for envionment issues on machines that host Phabricator, let alone environment issues on machines that Phabricator uses for builds).

cslint is deprecated, see T8978.

Closing this because beyond diagnosing initial configuration, there isn't much value in making things this much more complicated.

cslint is deprecated, see T8978 for more information.

We're no longer (at work) planning or intending on continuing use for EC2 blueprints. If there's anyone else out there that wants this functionality, feel free to re-open this task.

We're no longer (at work) planning or intending on continuing use for EC2 blueprints. If there's anyone else out there that wants this functionality, feel free to re-open this task.

It's not email client dependent - Phabricator is writing out the wrong URL when sending email.

I run into this problem a lot because workboards doesn't support custom forms yet :(

Beat me to it :P

I don't believe it was implemented; the third party Celerity stuff only supports individual files as far as I remember.

I have a mental scarmemory of this exception because there was a period there where I had to be manually cancelling tasks every week to clear broken commit imports out of the queue so the builds would run :3

(@chad you might want to just merge this into T5955 instead of me adding a blocking task, I wasn't sure and figured adding a blocking task was the least destructive thing to do)

Here's the official upstream task: T5955. Here's another report of the same issue: T7260.

This is related to JSON not supporting other character sets than UTF-8. It's a known issue (let me see if I can find the task).

Chiming in here because I'm now hitting this. I'm about to start filling out tasks on a workboard, but the global default view policy / edit policies are wrong for tasks by default, and I'm having to set those manually on every single task I create (I'm about to create maybe 20 tasks to plan out a sprint?)

I think it would be preferable to keep a log of bulk edits that were performed in a global(?) history, and allow them to be reverted easily? I think that would mitigate the issue described in the comment above, and provide value in the event someone unintentionally bulk edits the incorrect set of tasks / objects.