Ok so I just took it for a spin while editing herald rules. While it sort of solves my problems, it's very much a poor-man's solution - it's completely out of the way from the "create a herald rule" workflow - ideally, on the page where I'm creating or editing a herald rule, the test console should be right there so I can try out my new rule without necessarily having to save it; also it would filter to just trying that rule instead of trying all the rules, which would cut down on visual noise. This sort of change would make it much easier for the non-power user to create working herald rules.

I have been trying very hard to run arcanist / pharbicator /libphutil unforked until now so I would strongly prefer not to edit any of the source code. The second issue is that this is being run as an external command since it's a drydock build step.

IIRC, the "right" thing to do here (According to that article), is to exit with 0 in all non-exception cases - i.e., even for failing / unsound / broken tests - basically, remove https://secure.phabricator.com/diffusion/ARC/browse/master/scripts/arcanist.php;ccbaee585e1a350d1ff970c30481079dc8471a7c$399 and expect exceptions whenever something is wrong.

Sorry to be a bother on this again. Today we almost got bitten bad by this again since the unsound test returns an exit code of 1 and the failure was actually a class not being loaded because the user had not upgraded arc on the machine.

Yeah, I think the existing "Edit" page should really be more like the "Manage" page in Projects that anyone who can see the repository can see.

Also, view the edit history: https://phabricator.wikimedia.org/T128679

If anyone else set up a cron job or similar to keep a staging area with a fresh master, you should be able to throw it away after users upgrade past T10509. That task has some details.

Aha! That makes sense, thanks for digging into it!

tl;dr: looks good!

That would actually work for us.

If the motivation is primarily social, you might be able to use a social permission:

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.

Part of the pathway forward here may also be to reduce the prominence of subprojects in typeaheads/lists, or reduce it conditionally or something.

This is currently intended, although I think it's not out of the question that we might relax it or otherwise take another look at it.

Awesome, thanks!

I have a 500mb repo somewhere, and it would reproduce very easily to me, so I'll test this.

Yeah, it was complex enough that I didn't want to suggest an outcome design too strongly. :-)

This is probably at least somewhat reasonable, and we do something vaguely similar in the Maniphest list view.

I'm a little worried that doesn't make for a great out of the box or support experience since almost anything interesting will require extensions, but that is basically the case anyway today.

I'm very open to making build variables extensible, but I think the bar for upstream defaults needs to get stricter and become "this is critical information for many build processes", not "this helps to simplify at least one build process on one install somewhere in the world".

Is it reasonable for this value to be part of the job name?

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"?

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".

I plan to address timeline / commenting separately after most/all layouts are converted.

I don't want to add upstream build variables in every case where they'd make things more convenient for someone, since that could get out of hand quickly.

how to make the job smart enough to call back

The API endpoint for "make an http request" is ci.example.com/job/{repository_short_name}/build

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.

Yeah, my expectation is that whatever's on the Jenkins side needs to know about Phabricator, because it needs to call harbormaster.sendmessage to report results when it's done. So it seems like the job has to be some-harbormaster-aware-build, and like it should be able to look up the repository name without undue work, as it already needs to know how to call Conduit.

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.

Why is the approach used by Uber's Jenkins/Phabricator Plugin (which does not require repository.name) unsuitable in your situation?

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.

Since that sounds possibly plausible, I'll confirm that timeouts end up looking like this in the UI, and repurpose this for "make timeouts readable to humans" if they do. I can dig into it some more if that turns out to be a dead end.

You control that API though, right? And could conceivably expose /harbormaster/job/{repository-phid}/ or whatever?

It should not require more than 60 seconds, but rather less than 1 second. Only the Jenkins instance running inside a Windows VM has this intermittent bug though. So it still sounds like a reasonable explanation: maybe Jenkins in Windows gets suspended if not used for some time or the VM itself is paged out on the host HW and takes forever to become responsive, who knows...

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.

If diffusion.search existed, you could call it with repository.phid to pull the short name, callsign, ID, etc. Would this be sufficient?

Also known as the far more hilarious CURLE_OPERATION_TIMEOUTED.

This may be cURL 28, CURLE_OPERATION_TIMEDOUT. We have a 60-second timeout on this build step. Is it possible your server requires more than 60s to acknowledge the initial request?

That is, it already supports subscribers, the field just never got built in the UI.

We probably will build this sooner or later since it's free when Countdown eventually swaps to EditEngine.

Sounds good. I'm going to close this out since we don't plan to pursue the particular rule it describes and I think other related work is already covered elsewhere.

After D15427, this should be pretty clear for "Land Revision".

Importing SVN repositories as single repositories is recommended (Facebook's had several million commits in 2011, IIRC).

This hasn't happened again and I think it's less reasonable to expect it to work in modern Phabricator.

I think this was resolved at some point -- this is the behavior at HEAD, which seems broadly reasonable:

See also T2225 for a concrete issue caused by showing enormous numbers of paths (unbearably slow page loads because of the raw wire filesize).

This was fixed a couple of years ago in D4730, and works fine on the modern LLVM install: http://reviews.llvm.org/rL170845