That's entirely reasonable, but completely unclear from the task title, reproduction steps, description, or other context here. Here's an example of how you could have filed this task instead to make the root issue more clear:

This task does not describe a problem that is in any way related to reclaiming unused resources or autoscaling hardware pools.

You don't need to examine the remote branches beyond git fetch, which I'm assuming has already been done when the working copy is fetched. You just need to map the local branches to the remote ones (you can actually just do this cp .git/refs/remotes/origin/* .git/refs/heads).

In T10027#150524, @epriestley wrote:

I don't know of any scenario in which physical hardware or renting virtual machines is cheap?

I am building Harbormaster and Drydock for commercial companies, where the cost of hardware is small compared to the cost of personnel. I believe this to be true for essentially every commercial company. It is true even for us, and we don't pay salaries! We pay more for health insurance than for all development and production hardware combined. Hardware is incredibly cheap compared to personnel -- even personnel who work for free.

Building something generalish here may be the best way to unblock D14802, and to reduce the amount of regression behavior from T9905 (I am missing the preview a little myself). I think we need click-to-preview in some cases (mobile, Conpherence) anyway, so my tentative plan is:

Given how much of a backlog there is here and how slowly I've been able to move through it historically, my initial thought is that there may be no mid-term and T5055 is the pathway forward.

That would needlessly slow down working copy construction in the common case, by adding extra unnecessary steps. Have your build tools examine remote branches instead of local branches, or do this synchronization yourself at the beginning of your build, or wait for T9492 and use "one-time" working copies in exchange for inefficient working copy construction.

I'm not actually after a "current branch"; I know that there's potentially unlimited branches for the current commit. What I'm interested in is actually having the branches from the remote fetched down as the local branch names, so that "master" locally is the same as "origin/master" and "abcdef" is the same as "origin/abcdef", or to put it another way, as if the repository had been freshly cloned with "git clone".

This report doesn't include reproduction steps which allow us to reproduce the issue you're encountering. See Contributing Bug Reports.

I believe this was resolved shortly afterward, in connection with T6884.

I don't know of any scenario in which physical hardware or renting virtual machines is cheap?

There is no such thing as a "current branch" in this sense in the general case. Harbormaster builds commits, and a commit may be on anything between zero and infinity branches, and may be the head of any equal or smaller number of branches.

I'm going to see if I can make libphutil compatible with this library which might involve some hackery such as in D14523.

(The fix isn't retroactive, but should apply to newly created subtasks.)

Hmm, are you expecting that Harbormaster builds will only ever run for a few minutes then? The text in the Drydock documentation seems to indicate that you don't expect people to run builds that take hours.

This task seems to describe expected, correct behavior of limit ("builds for one project ... block builds for other projects due to Drydock limits being hit").

Anyway, if the intent is that the limit property shouldn't used and it's usage isn't supported, then perhaps it should be removed?

I don't believe so, https://secure.phabricator.com/T4209#146794 clearly states that until that patch lands, daemons and repos must run on the same host.

Well my point is that I need some equivalent of "Lease Working Copy" that just provides an empty folder to work in.

I don't know of any scenario in which physical hardware or renting virtual machines is cheap? That seems like it excludes Drydock from being suitable for literally any system where you need to run commands on machines :/

I don't know what reliable reproduction steps you expect here. Drydock doesn't really give me any indication as to what it's doing or why it's doing nothing. The screenshots clearly indicate the issue at hand, and the accompanying text indicates what I did to reproduce the issue on my install.

I think T4100 and design changes elsewhere sharply reduced the need for this, and don't anticipate pursuing it any time soon except perhaps as part of adjacent tasks like T5307 (and maybe T10034 and T4863).

I don't currently plan to pursue this, as I think form customization fixes about 80% of this problem by letting you create multiple different create forms (as on this install), and will likely get to 85% or 90% with further refinement.

• D14849 should fix messaging around "Create Subtask".
• I'm likewise unable to reproduce the original issue at HEAD, so I suspect it may have been fixed elsewhere. If anyone has repro steps that work at HEAD, let us know.