I'm just tracking this in T10004 now, there were a couple of other reports kicking around but it didn't make it onto the list originally.

This report does not include reproduction steps that we can use to reproduce the problem. See Contributing Bug Reports.

It doesn't make sense for "Lease Working Copy" to not provide a working copy.

You can probably set it to "0" to achieve the same effect, but this is a bug and I can reproduce it locally.

See https://secure.phabricator.com/book/phabricator/article/drydock/

This will be available in a future repository.search method, via T7715. See here for some discussion:

This is far outside even the far-future scope of Harbormaster.

I thought that it should still work because I'm running the repository pull daemon on the worker host?

Thanks @epriestley . It seems my search skills failed me this time... :)

Right, try stopping the pull daemons on the other tiers and leave only one running on the repository machine and see if that resolves your issue.

Sure, I get that... But the import is failing even on the instance running without the --no-discovery flag.

In T9905#150315, @nicolast wrote:

I lost the preview (after a code update) while creating a new task on Maniphest. I it possible to restore it?

Please excuse me if this is not the place to ask for this:

It means you don't need to run the taskmaster daemons on the same machines as the repositories because it can just make a Conduit call instead. You no longer need to run separate daemon tiers or use the --no-discovery flag.

I don't think that would fix the deadlock issue, which seems to be the root cause?

D14846 should fix the package case, but I'm going to leave this open for followup work: Files, Pastes, Maniphest should get indexes; and we should replace the powerful systems in Projects and People.

As general infrastructure cleanup, I would like to split the existing SearchEngine and DestructionEngine components apart...
As part of this cleanup, we should also fix T9890.

I found the other task by searching for "blocking others".

In T5422#146501, @pgiles wrote:

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

You probably need to apply D11874, which fixes this issue.

Right now all of my build plans have "Wait for Previous Commits" so that builds for one project don't block builds for other projects due to Drydock limits being hit.

@chad.Thank you so much for your response.Actually the problem that I am facing for "Install Pygments to Improve Syntax Highlighting"
I install Pygments using comand "sudo apt-get install python-pygments"
Now i have enable pygments.enabled configuration option.So,Please Let me know how can i enable it?
Unable to get configuraton file.

My concern is that the regression tests will consume all of the Drydock leases, so other builds that need working copies on the host will stall until all of the regression tests have finished running.

Why do these plans need to run sequentially in the first place?

We had only imported one repository when we saw 0.00% progress and nothing but errors on the logs. I'll delete the database and reinstall Phabricator, this time with just our dummy test project to see if it finishes importing.

Seeing this on the repository host:

Nevermind, this was my fault... the webserver was running a different version of the codebase than the rest of the cluster.

Nevermind, this was my fault... the webserver was running a different version of the codebase than the rest of the cluster.

sorry about that "elvis_i3 closed this task as a duplicate of T10025: Can't set a default space for tasks created through EditEngine."

Same here... Sadly D14801 doesn't fix this issue.

By importing repositories, you have amassed a large number of commit import tasks. By deleting those repos, you've made all these tasks obsolete, and they will fail in this manner.
Your safest action now it to wait it out; You can increase the number of task-processing daemons by running ./bin/phd launch 4 PhabricatorTaskmasterDaemon, and let them clear out the bad tasks.

The exception is correct in that the reviewers field contains garbage:

Indeed, there's nothing there by that ID - but why?

So I managed to workaround this issue. First I reset all the attributes of the blueprint with:

I just restarted the first build and looked at the lease that was trying to be obtained:

This is what I see in the daemon page (there are two builds trying to get a lease on this working copy blueprint):

Apparently even new builds that are trying to use this blueprint are now stalling.

Ok, i misunderstood the withMemberPHIDs reference. I thought you wanted to get all the members of a parent project including it's childs.