- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 22 2015
Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github?
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.
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.
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.
(The fix isn't retroactive, but should apply to newly created subtasks.)
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").
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.