I don't want the error messages to just disappear since I worry that might be confusing, but I've added an option to dismiss errors once you're done with them in D14886:

Yes, that is expected behaviour. Only failed Harbormaster builds generate Feed transactions.

Apparently only failed build events are shown.

No, this works out-of-the-box for me.

In T10052#151003, @hach-que wrote:

I definitely see Harbormaster events in Feed queries, so I'm not sure what this task is asking for:

I definitely see Harbormaster events in Feed queries, so I'm not sure what this task is asking for:

I'm going to merge this into T8509 because it's directly adjacent, although this issue is slightly different.

This works for me now! Thanks!

(That's not possible for all issues, like the conduit.deprecated.* issues, since those no longer fire.)

We should probably provide a way to do this, but a workaround today is:

I'm going to merge this into T10004 just so it can be friends with everything else there.

Right, but that's because to me master being incorrect is a symptom of all branches being incorrect, which is what the task title and reproduction steps demonstrate.

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:

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).

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.

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.

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'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.

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

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

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.

Your pirate translation (006321cce76b00c3c).

What version of Phabricator are you on?

Use spaces, a positive "open source" project or custom field, make "Games Project" public, or use a public negative project which is a companion to "Games Project" (Herald rules could enforce that it was added when "Games Project" was added and removed when "Games Project" was removed).

How would I exclude tasks for projects that are not visible then? Or do I have to tag every single task with like an "Open Source" project and then make it filter based on that (this is undesirable because now every task just has a project on there so it can be queried on)?

This is expected. Queries using projects you do not have permission to see are not valid, and do not return results.

Quote shell arguments which contain spaces or special characters. This flag behaves just like git commit -m ..., svn commit -m ..., and hg commit -m ..., and the quoting rules are the same shell rules used by every other shell program.

did you try quotes?

Oki.

This is the current intended behavior.

Steps:

1. You click at "edit task" or "new Bug Report" or "New feature request",
2. Click at "configure form"
3. Click at "view form configuration"
4. Choose now from the side bar the option "Reorder create forms" or "Reorder edit form" (Second one is not reproducible here, because you got only one visible edit from at the moment)
5. Then you can reorder the forms as normal user, so everybody can make chaos, if you got more forms, he can destroy the logical order.

Please follow Contributing Bug Reports when filing bug reports. Specifically this report lacks steps to reproduce the issue.

Thanks @epriestley! I'll try it out.

@nickz I believe both issues are now fixed at HEAD. Let me know if you run into anything else.

Okay. You can implement the behavior you want like this:

In case the case of a limit being set, then yes, I expect it to fail immediately (and I expect them to fail until the resources drop below the limit).

I would expect 4 of the builds to fail as they can't allocate more resources.

I would expect 4 of the builds to fail as they can't allocate more resources.

How would you propose Drydock detect that it should fail if the situation is a legitimate deadlock that can not be alleviated by cleaning up resources?