In T10623#165958, @epriestley wrote:

Can you describe the root problem? What kind of rules are these? Revision rules?

I filed this primarily to ensure there would be task in the upstream. I fully expect this to rely on T10329 (and believe I even commented in that task).

In T10621#165969, @epriestley wrote:

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

We'll try that in our next upgrade. Thanks for the help!

In T10560#165431, @epriestley wrote:

Should we get rid of the <commitID, isDirect, changeType> key, then?

The discrepancy between staging + production is almost certainly caused by the size of the data.

You do not need to create a secondary index on changeId as that is the leftmost part of the primary key. The secondary index just points to the primary index where the data is stored.

The underlying cause of the slowness is because the stats were completely off in the production table (was showing cardnality of 18 for changeId).

See also T10038

In T10574#165181, @Luke081515.2 wrote:

In T4887#164619, @Luke081515.2 wrote:

Maybe a good idea too:

• What about if you can configure at owners, if the owners should added as (blocking) reviewers automatically? Makes this simple too.

Quick update here. We've found that adding FORCE INDEX (primary) results in 79.4ms in production even without the key_history index.

See Also: T9640

In T10584#164865, @avivey wrote:

GitHub actually encourages reviewers to "Add commits to PRs"; It's a little hard to un-teach once it gets hold.

Interesting. I just went and tried it again and different times its failing in different ways. I'm going to give up and assume this is something wonky in my browser until I prove otherwise.

1. Go to a project, e.g., https://secure.phabricator.com/project/view/1408/
2. Click manage - see https://secure.phabricator.com/project/manage/1408/
3. Click "edit details"
4. Select "visible too"
5. [ note that the current policy is "custom policy" ]
6. Select "custom policy"

T8887 is also related to this task

Hrm, I'm going to do some followup with our DBAs as well. The performance numbers above were copied from the DBA analysis; however, when I make the change in production, rather than in staging, some of the behavior does not directly replicate.

to clarify: I removed the key I originally added

KEY `commitID` (`commitID`,`isDirect`,`changeType`)

was I not supposed to do that?

KEY `cidid` (`commitID`,`isDirect`),
KEY `cidct` (`commitID`,`changeType`)

are the keys created

That variant of the query is slow as well.

to clarify

KEY `commitID` (`commitID`,`isDirect`,`changeType`)

IMPORTANT: This is not a demo or test install. Please don't make a mess. You can launch a demo install on Phacility if you want to poke around and try things out.

That would actually work for us.

We also have an interest in this. For us it isn't about 'trust' but about social expectations and affordances. We want users to talk to us before making a global project, but to be able to divide their own team as they wish.

In T10517#163739, @epriestley wrote:

Maybe this is a better question: if someone else files a similar task saying that the repository projects or date created or full list of tags or default branch would help them glue to Jenkins/Travis/Hudson, when should I say "yes" or "no"?

In T10517#163725, @cburroughs wrote:

(In other words this is about "how to call the right job" not "how to make the job smart enough to call back".)

This is exactly correct.

Having a layer of indirection to call off another jenkins job is a much larger step. Not unreasonable but a level of complexity which is more than just "make one more call to conduit".

The remote is aware of phabricator. We just don't have a hardcoded job
name like uber does.
It isn't hard for us to add indirection but IMHO this adds needless
complexity.

In particular. See the screenshot here: https://github.com/uber/phabricator-jenkins-plugin/blob/master/docs/harbormaster-plan.png test-uberalls is a variable for us.

There is a different job per repo. What might work for us is a special phabricator job that uses diffusion.search to figure out the short name and then set off the correct job. I suspect this is more convoluted than ideal but likely works.

To be clear: this API is jenkins. It isn't unique to us or proprietary. The repo short name is exactly equal to what Jenkin's call the "job name"
The most unique part perhaps is using the short name rather than the callsign. That said, we want to move away from callsigns and Jenkins predates Phabricator for us.

The API endpoint for "make an http request" is ci.example.com/job/{repository_short_name}/build. We don't need to push much more than that but in order to construct the HTTP request we need the short name.

Not sure if related to this task or not, but I'd love the ability to have Herald rules act on countdowns. Sometimes we have tasks that fan out to many teams and we'd like the ability to assign it to the team, but add a project or change assignee once a countdown expires.