• (T9516) Use the same copy/paste line number stuff that Paste, Diffusion, etc use.
  • (T10179) Make formatting smarter. For example, the "Run CircleCI Build" plan produces logs that we know to be HTTP headers (which we could format as a table) and (almost always) a JSON blob (which we could format as human-readable JSON).
  • (T8656) Make one of the smart formatters "ANSI".
  • I'd like to style this like other stuff (Paste, Diffusion) and let users pick dark themes globally with T5701 if they prefer.
  • Logic for loading the data is clunky, and fetches much more data than it needs.
  • Clicking pager links affects all build logs on the page, this should probably be JS-ish at some point.
  • Pager logic often feels clunky to me. For example, if a log is exactly 21 lines long, we still show pager controls. If a log is 27 lines long, we should probably show the whole thing. "Show more" would be more consistent with how other pagers work, etc.
  • (T6139) Not sure if this is really the right way to frame it, but we often have information about how useful a build log is and can do a better job of organizing them (e.g., successful build logs are usually uninteresting and could be folded by default).

@hach-que, that plan sounds good to me.

Not directly to your point, but you can remove or shorten the [Differential] token by adjusting metamta.differential.subject-prefix, if you didn't stumble across that already.

I'm still not really thrilled with where the documentation situation on repositories is, but it's getting a little more manageable.

Here are a few ideas that might shed some light on what's happening:

I can't reproduce this. Here's what I did:

arc diff is supported, but most of these reproduction instructions don't make much sense to me in the context of arc diff -- for example, arc diff does not apply patches.

Specifically, any effort to reproduce this in the upstream will meet this grizzly fate on the arc test step:

Yeah, arc test is not part of the upstream.

This is a Bitnami issue, and you should report it to them. See Contributing Bug Reports:

Maybe also reasonable would be something like this:

One thing we could do to improve this is version daemons in /daemon/, so your "go to sleep" routine could be more like:

You can use bin/phd reload -- instead of restart -- to instruct daemons to exit and restart only after completing their current tasks, with no time limit on task completion. The semantics on this are necessarily a little fuzzy, but basically:

This document is already large and complex and the source of many configuration mistakes. I worry including basic information like this could cause more harm than good, by making the document even larger and making it easy to miss something important.

That is, we normally navigate complex configuration by verifying every step and just telling you what's wrong and how to fix it (e.g., moving all the MySQL, etc., configuration from documentation to automatic setup issues was a huge step forward), but there's basically no test we can perform on most of this chain.

In general, this configuration is a huge horrible mess but I'm having a hard time coming up with ways to really fix it that don't just tell you to run everything as root.

Oh, I think I have a handle on the first issue -- you can ignore my questions about that.

It turned out that the git-user (aka vcs-user) created files as phd:phd

This also reproduced locally for me (OS X Yosemite, openssh-6.7p1), and chmod on the parent directory alone was reliably sufficient to prevent SSH from working. The instructions already suggest a root-owned location, but D15794 notes this requirement explicitly.

I can confirm T9560 locally, at least, so that might be the problem or part of it -- maybe start there? If you can provide details we're happy to fix this properly.

Yes, you should NOT set AuthorizedKeysCommandUser root, this is needlessly dangerous and gives the script substantially more permission than it needs.

I also caught this vaguely related downstream report of markup list styles not rendering properly in mock descriptions:

After we receive a push, try very very very very hard to release the lock if we're the thread holding it, even if we lost the global lock

Any test we execute must be distributed with phabricator/ and run on the first page load after an upgrade. That generally means it needs to be small, very fast, and completely conclusive. Compare to the test for Shellshock here, which runs in a few milliseconds, requires 10 lines of code, and is totally conclusive:

We'll fix this eventually, but probably not until the next time we do major work on Phriction (T9379) since the impact is very minor.

Thanks! The intended instruction was just "don't specify ssl.key, ssl.cert, etc.". D15787 should fix it.

I don't have to click "Cluster", it's just a subheader. Are you seeing something different?

FWIW I have updated to Ubuntu 16.04 locally and haven't had any issues with Arcanist.

A few things that might motivate writing an API panel (which pulls from external sources) instead:

(I agree that this is a bad solution for notifying users of downtime/maintenance on the current instance, and that rooster/broadcast is better.)

Maybe T8145 / T5231, but I think the driving use case there was "notify users of Phabricator downtime" specifically. I'm imagining the driving use cases here not affecting all users and not directly impacting Phabricator, just having wide enough impact that there's interest in surfacing them more broadly. e.g., "We're having a production incident affecting video upload, ops is investigating" is important, but not "every Phabricator user must be notified" important.

Doing a Phriction panel, an iframe panel, or a custom API panel would also be reasonable approaches.

Here's an example I could imagine us doing: we have some button on admin.phacility.com that says "Start a deploy". When that's pressed it causes these actions to occur:

This one seems OKish to me -- I think those use cases are pretty reasonable and root-problem-ish? I'm assuming "waht's currently broken" and "can we do deploys" are information known by some other system or tool.

I think D15784 should fix the issue. It should land in master later today and be available in stable in about 24 hours. Let me know if you're still seeing issues once you update past that.

I think I know what's going on, although I'm unsure why the <2MB files would work, unless you happened to push those to a public ("Visible To: Public (No Login Required)") repository and pushed the large files to a private repository?

• Is security.alternate-file-domain configured on your install?
• When you say "redirect to the correct file", do you mean you get taken to the file detail page /F1234?
• Also, do you have rP37b93f4 locally (April 7)? (You can grab the hashes in Config → Versions if you aren't immediately sure and I can figure it out from there.)

You shouldn't need to configure diffusion.allow-http-auth -- the auth token is basically the first [shortened] in the URI, so that appears to be working properly.

I think we generate this warning long before attaching the diff to a revision, so it isn't trivial to know where to look for a "you already confirmed this prompt once for the current revision" flag.

We appear to be stable here now:

This is also maybe a good time to fix all the bad old mysql vs mysqli stuff, mostly:

I can't reproduce this. For example, this host does not reproduce the issue:

D15781 is promising and it looks like we can do this purely on the client if it has relatively old PHP, without requiring relatively new MySQL and special configuration on the server.

Mixed progress. Repository clustering has been stable in production since the last update, and appears to actually work, which is good. We've hit a few minor snags (like a missing sync-before-read in diffusion.querycommits) but all pretty much expected stuff and nothing troubling.

Like just don't show it at all? That seems reasonable to me, although 0.00000000001 is very funny and we would be losing a truly great joke at such a young age.

That's because it was deliberate self-subscribe which is so completely boring that we normally wouldn't even show it. I think it's arguably correct to show the Herald story? Maybe?

Thanks, I think that should be fixed now. Not clear if it was related to everything else and I can't immediately come up with a way that it would have been -- I'll keep an eye on it. We've made some changes to the Aphlict server recently and it might have some issues that still need to be worked out, so it could be purely coincidental.

The diffusion.querycommits method needs to sync-before-read (at least, if bypassCache is provided?) but currently does not. This can lead to tasks failing on the daemon on an un-synchronized node. Things self-heal, but it would be nice to prevent this.