See Planning for discussion of updates and timelines.

What are the barriers you face to hosting on Phabricator instead of on GitHub?

The provider is now being removed from Phabricator, so 2016 Week 49 is the last release to include it.

Generally, I am leaning toward splitting the "Commit" rule into two rules, "Commit" and "Ref Update".

We have some spooky magic around "autoclose" which might make the behavior for "Is on autoclose branch" different than "Is on <specific, named branch>". That said, I'm not sure if it's actually materially different, and these likely end up being more-or-less the same thing when we actually fix them.

T11953 isn't exactly the same as this, although they're similar.

Oh, maybe this isn't quite the same as T6522. Pushing another commit to the branch probably fires the rule?

This has been running cleanly in production for roughly two weeks, and appears stable. secure001 stopped writing Files data at F1943597 and we're now at F2078289 on secure003. We saw a couple of minor setup issues (mostly: exception messages not being tailored enough) but no fundamental issues.

We also made some changes to this recently (D16936, D16983) and it could conceivably be a version issue, but neither of those changes replaced a static cache with a RequestCache or similar, and D16936 is correctly using the RequestCache (which is cleared when the taskmaster de-queues a new task).

I can't reproduce this in the Phacility cluster, either. Here's what I did:

I'm not immediately able to reproduce this. Here's what I did:

From elsewhere:

I believe this is now resolved at HEAD of master. Let us know if you're still seeing issues after updating.

I believe HEAD of master can now accept IPv6 requests, with the caveat that most of my testing has been at least somewhat synthetic and I haven't set up a legitimate, dedicated, IPv6-only host anywhere to be certain it works. That said, I'm reasonably confident that my synthetic testing was fairly thorough, since not very much code really cares about the remote address and I was able to make legitimate requests to ::1 over HTTP and SSH, and from synthetic IPv6 remote addresses. If you run into issues with sending IPv6 requests to Phabricator, let us know.

I'm planning to support this in the arc experimental branch, although initial support won't be optimized. We can look at ControlPath and/or adding batching to the protocol layer to improve performance once it works.

I'm going to merge this into T550 since it sounds like that's the immediate way forward, at least.

The section in T11922 only applies to the storage engine portion of that change, not to reindexing in general, and dropping the index is likely to hurt things overall if we need to do this more in the future (no performance improvement but totally nukes the search index until the reindex occurs).

Cool. For context, stuff I expect to do upstream, sooner or later, since I consider it unambiguously good (just not necessarily high priority):

Can you outline the attack scenario or scenarios you're concerned about?

Good enough for me.

(I don't consider is a bug: we're consistent about showing modified date across all applications which show a date, as far as I can tell, and omitting a label is a product decision.)

I think we're currently consistent about showing updated date (Diffusion, Differential, Maniphest, Phriction index view).

Hmm, I'm having trouble reproducing this. Here's what I did:

As above, we don't support installs that don't follow our guide.

I think this is fixed now (config change on the Mailgun upstream side). Let me know if you're still seeing issues.

Test v4

Alright, thanks. I'll bring up a test system with a more modern git.

Just to double check, does git merge-base e032e3606960 45936140fc3a in the working copy that you're trying to push print 45936140fc3a?

Thanks! We can just improve this error message, which should resolve the problem more directly.

If anyone has a reproduction case that they can test without undue disruption, try this patch against phabricator/?

It looks like this is expected to work without changes, but relies on some environmental variables being passed from the hook environment to the child environment.

The Git mailing list archives also aren't currently working for me (no DNS record for blog.gmane.org?) so I can't tell if there's any existing discussion of this.

This is likely the relevant change:

Thanks, that's extremely helpful. I think D16974 + D16975 should fix the bug (and an adjacent bug I hit while testing the first fix).

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

In the general case:

I'm pretty sure this this was just a straightforward fix that escaped detection for this long because any other repository edit would rebuild the index. D16972 rebuilds the index on any repository URI edit. Let us know if you're seeing issues after that. Thanks for the report!

We aren't interested in introducing complexity into Phabricator to work around limitations in GCloud SQL at this time. Instead, you should ask Google to fix this limitation with their service.

Does making any other edit to the repository (e.g., changing the description) correct the issue?