This was resolved as part of T13630. I didn't actually put it in the UI anywhere, but all requests will now originate from 13.56.71.101, and this isn't likely to change given the wind-down of Phacility hosting.

See also PHI1987 for another case of this.

Committer identities ... they're currently stored in a JSON blob so there's no efficient way to query them.

That was sufficient to get what I needed, thanks so much.

Is there a way to find which object(s) an (unmapped) identity was discovered on?

Is there a way to find which object(s) an (unmapped) identity was discovered on? After a rebuild-identities, I have an empty string identity and a couple asdf-style garbage ones. I'd like to find the source of them and either fix them there or see the context to understand the appropriate identity mapping.

I think (?) this was pretty much resolved by the last round of changes. See T13291 for some followups.

Thanks! I didn't know it could be done from the web UI.

You can open the revision in the web UI and "Request Review". You can use arc diff --browse ... to open the web UI automatically.

We just found a real issue with this, different from what I mentioned above: We had an issue with our CI machine, and to fix it we needed to make a diff. But as the CI machine is not working, the diff won't build, which means we can't accept the diff that will solve the issue.

Is there a way to disable this option via a config in the server or a CLI parameter?

Perfect; thanks!

In the general case:

Sorry if this is a stupid question, but now that this is done, how do I actually map between Phabricator users and VCS user strings, in an existing Diffusion repo?

I think this doesn't have anything actionable left, see T13444 for some followups. This feature probably isn't 100% perfect quite yet, but I think remaining work is just cleanup.

Any update on when this is going to reach stable? We're ~16 weeks past the earlier estimate...

PHI1224 describes a somewhat-adjacent situation: an install would like a way for external automated tooling to reference source files and generate editor links for them.

(Sorry, typo'd my own name into another @ep....)

It seems that newer versions of git have become more aggressive at detecting binary changes as moves + renames, because my install is now hitting this on a very frequent basis

You will soon be able to give builds different "Hold Drafts" behaviors. See T13258.

A related issue here is exemplified in https://discourse.phabricator-community.org/t/importing-libphutil-repository-on-fresh-phabricator-triggers-an-error/2391/, which basically amounts to:

This doesn't have a repro and will probably be fixed via rewrite / modernization in T13077 anyway.

@bgamari Did you ever find a solution?

I did rebuild-identities on every instance

The "activity" migration went to production just now. I expect all production instances just bailed out, since I ran rebuild-identities some time ago, but I'll verify that:

In T12164#239595, @mydeveloperday wrote:

just wanted to give you some reference data (your mileage may vary), I have 2 Phabricator instances with multiple git repos

one has ~300,000 commits ( a mixture of read-only (mirrors) and hosted repos), the other ~200,000 (all hosted)

in both cases I ran rebuild-identities after doing the Week25 upgrade

time ./bin/repository rebuild-identities --all

it took

21 minutes on the one with 300,000 commits and
16 minutes on the one with 200,000

Can't help but think that this was most likely limited by the speed of the terminal output.

Hope that helps others

just wanted to give you some reference data (your mileage may vary), I have 2 Phabricator instances with multiple git repos

I deployed D19484 and db010, db024 and db025 finished up with no issues.

These hosts ultimately timed out on the initial rebuild-identities: db010, db024, db025.

From T13152 -- none of this is too important, just didn't want to lose it when I close that:

See PHI594, where a real user had the same human name as an external user from another project.

@epriestley, can you confirm that the above patch should disable the draft state? I have applied it to GHC's Phabricator deployment yet we are still seeing Differentials opened in draft state.

Yeah, this is a combination of a bulk editor bug (which lets you delete task titles) and legacy compatibility code for transaction title rendering (which treats null -> anything transactions as "created this thing.").

Oh, good, it's about time this task be created!

Duplicate of T8936?

When this eventually moves forward, it's probably also appropriate to remove the syntax-highlighter.engine config option. I think this has essentially zero use in the wild and we have better modern patterns to approach the problem (without extreme-niche config options) if there are real-world use cases.

GHC recently upgraded its Phabricator installation and has been rather unpleasantly affected by this feature. We have multi-hour CI jobs, which often queue to a day or so of builds. Making contributors wait this long before receiving feedback is turning out to be rather problematic.

See T13069 for this and other similar use cases.

I'm going to roll this forward into T13069.

T11934 is a possible way forward on this (and other niche things) without adding a lot of Javascript and UI complexity, by supporting it through !fixes.

T10604 and T4369 do not impact LFS (broadly, they apply only to POST requests, and LFS uses PUT to upload data).

We have an outstanding support issue (PHI204) about timeouts with large files.

No.

@epriestley Are there any more concrete plans for this "nonblocking" builds? That is something we would like to utilise for one of our projects. Actually quite important as waiting for builds there is slowing us down quite a bit now.

Per above, pushes to staging areas did not push LFS in the past. We should figure out what the state of the world is now and try to resolve it in the upstream, and document anything we can't work around or resolve.

@Grimeh, above, reports that this doesn't work over HTTP. I believe it does, but we should verify this.