Presumably this will be addressed when upstream implements running or embedding build plans.

We'll keep this patched locally while-ever we keep encountering the issue.

The same here...

That's sensible to me. Was just an unexpected side effect of improving the arc land workflow for git and thought I'd mention it.

See also T9515 and T7639 for "choose some other users to trust, if you lose your phone they can vote to strip your MFA".

This was an intentional change in response to requests by other users in T4333 and elsewhere.

On this issue, it would be great to tune the behavior regarding "Author date" vs "Commit date" for git. With our current CI tool, current build and previous build are determined in "Commit date" order not "Author Date', which can result in confusing links.

I wouldn't expect users to attach filetype specific filtering via the regex. The include portion of the linter config seems like a much better place to do such things.

See also T9640 for tracking PHP7 compatibility.

There isn't really one, all the applications that do it right are doing comments, and you can't do the same thing they're doing very easily. Audit does something but it's a mess. It should really just get restructured, I think.

So how do I fix this in Phame, Pholio, Ponder. I can't find a positive example.

Wauw, Evan, thank you so much for your debugging effort, for sharing your thoughts and your elaborate explanation. It's (seriously) highly appreciated!

So you have a machine full of unused working copies, and Drydock is failing every build instead of reusing them?

I've marked D14637 as fixing this.

This happens after upgrading Phabricator and having a build step implementation no longer exist; when the build plan runs you get an unexpected error. Getting the unexpected error isn't what's wrong - but that the buildable doesn't get marked as failed is incorrect.

What happens if a new configuration / request comes in that doesn't match any of the available 16 working copies?

still won't get cleaned up and instead Drydock will just fail to allocate.

It's running out of disk space because Drydock isn't cleaning up the working copies and they're consuming all the disk space.

So you have a machine full of unused working copies, and Drydock is failing every build instead of reusing them?

Because if I don't clean it up, then every build from then on will fail until I fix it?

I forget the origins (it's been like a year), but Nick Zheng or a user at our company found this confusing.

There are a couple concerns with this suggestion. Mostly, the core problem as described is "workboard has too many tasks". This is the problem we'd likely want to investigate and address.

We're trying to integrate with JIRA 7.1. Is JIRA 7 or 7.1 supported?

@chad I'm not very technical. Also I read a lot of your documentation. It clearly states that new requests should not start with specific solution, only use cases.

@chad T5240 seems to mix several solutions and a note about regressions. Also @epriestley noted several issues and options. I wanted to call this out as opposed to other parts of that conversation.

@chad ok thanks. I will move to that task.

It's the exact same task to us and there is no benefit from managing it in two places. Autocomplete for users in Remarkup, when built, will just work everywhere for free.

@chad I acknowledge that this is partly discussed in T3725. However it is a long conversation with many options and ideas. I would like to promote this part of that conversation. Also I would like to discuss the option of paid prioritization.

I just upgraded Phabricator, now the version is,

When this happens, there'll be hundreds of builds all running at the same time, which can result in hundreds of working copies for the same repository.

I'm concerned that it's difficult to give users a descriptive error message if the pattern is an arbitrary regular expression. What does your patch do when a filename fails a custom regular expression? Specifically, how does it help the user fix their filename?

Your install is fairly out of date. See https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#common-fixes

Phabricator Version d878f215617bb5a97bd5ea4145566308cb68d7e3

I don't know how to reproduce the behavior this report describes. See Contributing Bug Reports.

I can't reproduce this. Here's what I did:

What version of Phabricator are you running.. See Contributing Bug Reports

Yes, it's the breadcrumbs.

This one is totally my bad.
My intention was to make it less spooky to migrate individual pieces to the section construct (since the API remained largely the same), but the API weirdness was not worth it, and didn't even achieve that goal

fyi my Phabricator instance currently has 80 working copy resources open

Aaah! That makes sense.

@epriestley: The main motivation was that we had been maintaining these as cherry-picked patches on top of phabricator core, which required constant rebasing. It was ridiculous and not even necessary. Eventually I figured out that phabricator doesn't care if the auth providers live in an external library. I sure wish I'd figured that out in the beginning, it would have made things a lot easier ;)

@epriestley: FWIW I don't mind doing the work, and I would love to throw away all the hacky stuff we have right now.

I'm not 100% sure it actually works, but you'd just do this:

In T9860#146391, @epriestley wrote:

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

The problem is, we add a rule that includes "subscribers can view" to the policy - so even if it prevents mail from being sent, by the end of the herald processing, the user has gained 'can view' on the private task (by way of being CC'd) even though they should have never been able to CC themself in the first place.

I believe if you include a transaction which sets the CCs to the current CCs, it is guaranteed to run after any personal rules and will entirely undo the effects of any sneaky rules anyone might write.

In T9860#146319, @epriestley wrote:

What are you doing which can't be covered by Herald?

To configure the regexp in an .arclint option for the linter seems valuable, with a clear use case.

We also probably need to implement Phabricator Credits before we can add ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ because otherwise we'll just be paying Stripe for the privilege of having ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ.

(i don't want to charge users for stuff, I just wanted to say ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ)

what about a jimmy wales banner ad?

My major concern with pursuing that (or, say, "$1 to file a task") is that user expectations will be like billion times higher if something costs $0.25 than if it's free.

ᵐᶦᶜʳᵒᵖᵃʸᵐᵉᶰᵗˢ﹗

We need a Pay $5 to see this extension button.