@epriestley I might not get a chance to land this myself, so feel free to land it if you accept it.

Yeah, I'll probably add the extension when I get off work.

In T10308#158023, @cburroughs wrote:

We removed the default task link because in many cases, the link to all tasks wasn't used, wasn't useful, or wasn't the best link (e.g., maybe several links or a link with different filters would be better). Particularly, the link was often redundant when projects use workboards.

I find myself clicking on a project to get to a list of tickets and then realizing that doesn't work often enough to notice. Maybe I am just used to the old way? For projects I use a lot adding dividers, urls, and motivational quotes has been nice. But customizing every single little "tag" project with a unique url doesn't feel super fun. Would you be open to a "search for open tickets in this project" PhabricatorProfilePanel?

Since IAM role credentials are always rotating, anyone who wants to abuse those credentials (possibly to avoid using their own credentials which would get them caught) only has an hour at most. It's pretty easy to see who SSHed into the server in the past hour. Not so easy to see who might have had access to the filesystem, ever.

Yeah, it's just a bit tedious to go back through like 40+ projects in the system and add a link which is probably hard-coded and might break in the future (if the project gets renamed or something?)

Yeah, there used to be a button on the project page somewhere which linked you to the Maniphest query page with that project prefilled in the "Projects" query field. I used it for doing bulk edits on tasks a lot when cleaning up projects that were no longer active or on the backburner (like bulk removing assignees or bulk changing statuses from whatever they were to Wishlist).

Ah, I'm using it in conjunction with the bulk editor. The "View All Tasks" button used to take you to the Maniphest query page where you could then use the bulk editor to manipulate tasks.

With the new column design, there's no more "View All Tasks" button as far as I can see, which is slowing down my work today quite a bit. I keep having to go to the advanced Maniphest search and query different things there instead of just clicking a tag on a task and then going "View All Tasks" to find tasks like it.

Fair enough

Yeah I know, I'm just giving feedback in the event that your expectations for how users will see / use it was different.

Yeah that's why I was using sub-projects. But I kind of expected them to have the context of the parent project shown in UIs? Now I'm back to doing this sort of thing in subprojects so that I have the right context in various places, which seems kind of janky:

And knowing I could technically have a task in two subprojects is also somewhat unexpected - I guess I was looking for milestones (without their own end dates) that could be broken down into further milestones.

I think I kind of expected subprojects to act a bit more like milestones than they currently do - for example, the fact that a subproject doesn't have the parent project's name in it when it's shown against tasks isn't ideal ("Protogame Version" on it's own doesn't mean much; what if we have multiple projects with Protogame versions?), and this carries across to tasks as well (searching for "Sixty Seconds" doesn't show the subprojects).

Once I added a single task to the subproject, it started working again.

I just hit this exception when I had:

(Should I repost the task description as a comment on that task so it doesn't get lost?)

Yeah I realise they're prototype features (and I mentioned so in the task filing). I just wanted to document something that caught me off guard if it wasn't already on your radar.

In T10288#157504, @epriestley wrote:

If we're requiring setup and active management before we show a bar, maybe this bar is better?

(-----X~~~Y          )

The left side of the bar is "Start Date". The right side of the bar is "End Date".

... snip ...

This is something we've needed for like over a year or more, because we need to filter the importance of different things failing, or we explicitly want messages when things pass.

Ah, I didn't check if HEAD had an index for the unit table. We're about 8 months behind because we can't upgrade until we resolve all of the conflicts caused by the different Drydock architecture.

In the buildable page that lists all the builds, I was experiencing 6 second load times until I added:

Page loads in Harbormaster for us are almost instant after adding this index.

You can use bin/policy unlock to regain edit permissions of objects. See D7189.

The other aspect of Calendar is that you can't put Calendar events on a project's workboard, which is another area of visibility that we need to see these kind of meetings in.

It is actively being developed right now, as per the transaction log. Maniphest, Paste and Owners have already been converted over to the new APIs.

Judging from that merge, you should expect to have rebase conflicts when upgrading in future, since those Conduit updates will replace the existing methods (which your patch is applied on). When that happens, you should probably also be aware that the request parameters to Conduit and the returned response may be different from what you've currently implemented, so you'll need to update your build server system to handle it.

I wouldn't spend time writing a patch for this until @epriestley has weighed in and determined that it's an acceptable feature request and that it would be worth the time to review an external contribution for this (it's possible he'll just write the functionality himself). See Contributing Code.

This feature request doesn't describe a problem, see Describing Root Problems. What problem are you trying to solve by accessing this data?

I'm guessing this is still years (or decades) away on the road map, but we want to be able to run build agents in the us-west-2 region and our Phabricator cluster currently resides in ap-southeast-2. Having a way of replication repositories across AWS regions (by setting up Phabricator cluster instances in us-west-2 and having the repositories replicate over to them) would be very useful in terms of reducing our git clone times.

wait how do I get @epriestley points

Is there any intention to add support for auto-complete when typing like "T1234" or "D1234"? That would help immensely with instances that have a large number of tasks or diffs. I know there's been a few times on this instance where I've wanted to refer to diffs in task comments, but I can't remember the number perfectly so I have to open a Maniphest search to try and guess what number it was. Having it in the typeahead with the task / revision title would mean I don't need to spend time doing that.

I'm pretty sure it can happen anywhere; I've definitely seen it happen on Linux, but my guess is that it's much more infrequent just because you're unlikely to have GUI tools periodically running "git status".

Is the Phabricator IRC bot also deprecated, or just the web interface that logs IRC messages?

(Although another benefit of T6139 is being able to surface build logs in emails that are sent out, so developers don't have to dig for the answer)

I don't really mind how it's implemented; it's mainly that if another task is required to set the reason for failure, then what happens when *that* fails or is otherwise not run (because the error is too fatal for the script or application that's being run to continue). Harbormaster right now doesn't have build steps that run on failure, so there's no post-build steps that can be guaranteed to run to assess the failure result.

While I'm at it, I'll add that the lack of this feature is a significant cause for developers ignoring build failures. Recently we had builds failing for at least over a week without anyone paying attention because there was no distinguishment between "failed to clone because of some network issue" and "the database scripts are broken and someone needs to really fix this now". It's now at the point where developers just ignore builds because it doesn't tell them what's wrong, and nothing happens about broken builds until a build engineer realizes and emails the rest of the development floor.

T6139 is also a request for this (I'll leave it up to @epriestley to decide which way to merge it).

Looks like I need to update to HEAD, since the Conduit call works here.

Right now we're working around it by having another build plan called "Post results to Phabricator" which has phid and state parameters. This build plan then runs the following PowerShell on a Windows build agent to post the result:

Is there any documentation on configuring Jenkins for commit builds (instead of differential builds)?

You mean from a Harbormaster Lease Working Copy perspective or a Land Revision perspective (when it comes to nonsensical UI).

@epriestley What is upstream's opinion on this? Is it something that can be prioritized or have an diff submitted and reviewed against it?

We have patched around this issue locally with:

Yes, it was because the SSH agent wasn't running (on Windows). I would have preferred to have it error and not submitted the diff, rather than having to do "arc diff" a second time to get the diff pushed to the staging repository.

This would make flags actually useful. I think the last time I used them was years ago, and I've just been adding comments to tasks whenever I need to add personal reminders.

@epriestley Is there any capacity to get this Prioritized?

I managed to temporarily workaround this issue by upping the limits on the blueprints, but obviously that is not ideal if the machines can't sustain that number of working copies in parallel.

I think it might be possible to cause a deadlock with limited leases even if the Expected Behaviour is achieved, approximately by devising a build plan like this:

this is the best upgrade

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

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

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

The sprint extension is not developed by this upstream. and is not supported by this upstream. You should contact the extension author instead.

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.