We already have a path forward on the next iteration of Phriction, and it doesn't include this direction. Please read Contributing Feature Requests and Describing Root Problems if you have future feature suggestions, root problems are required for any request filed. Thanks!

Here's what we currently have:

I'm going to kick this out of the ops space since none of this should be sensitive.

On mobile, I'd probably just keep this element in a fixed position on the page

@chad, some design stuff I'm thinking for later on, about in case you have feedback/ideas/objections:

I'm going to fix the editor behavior and then call this done.

I'm just going to merge this into T11401, at least for the moment. That may eventually split out into application-specific tasks when it gets underway.

If you experience this, please file a new task explaining what specific messages you're encountering and why hiding these messages is a better solution than changing the linters to raise more relevant messages. I believe fixing the linters is always a better approach here.

Actually, I'm just going to WONTFIX this. We may actually fix it, but I don't currently see a legitimate use case for it described anywehre.

My expectation is that the workflow in the task description will generally show this:

Actually, that description is a little misleading, but I'll follow up in T10607.

I'm going to merge this into T10607.

I can't reproduce this:

In T12607#221036, @epriestley wrote:

This is also prrrrobably an awful idea, but in theory we could put, say, HAProxy on each host in front of Apache and have it queue connections while Apache was restarting. That feels like we're building a really flimsy house of cards, but it's something computers could technically do.

This is also prrrrobably an awful idea, but in theory we could put, say, HAProxy on each host in front of Apache and have it queue connections while Apache was restarting. That feels like we're building a really flimsy house of cards, but it's something computers could technically do.

Cool. Harbormaster integration will also give you other UI hints like these, to help communicate build status to reviewers so they don't accept a change which has failed or in-progress builds:

Yes, it would. We haven't fully integrated the build system with Phabricator, but I'll review the docs and see how much more work we need to do.

This isn't the end of the world, but it's pretty bad if you have a mixture of private and less-private threads (sidebar state and main panel state are inconsistent).

If you integrate with Harbormaster, users will be prompted explicitly when they try to arc land a revision with build failures:

Engineers are not hitting a prompt when landing, they are disregarding the unit test failure message or not reviewing why the build failed. Since the build failure is on an external system, the engineer needs to view this information separately (the system posts a comment why the build failed). The overall goal of a herald rule blocking the land is so that owner can communicate that checking in code without running or successful unit tests is not cool.

Can you provide some more context about why engineers are hitting the "builds failed" prompt, and continuing through it anyway with failing tests and/or nonbuilding code?

The current ruleset implements all those rules correctly, except that it 200's directly for /status/.

redirect to Javelin

On secure, two not-so-great fixes are:

Sounds good.

I'll file a task for "unfuck status check".

I think you might need to send a Host header to trigger the RedirectMatch... but the LB certainly isn't; it just knows IP/port/path. ¯\_(ツ)_/¯