Page MenuHomePhabricator

Implement `diffusion.search` and think about `diffusion.edit`
Closed, DuplicatePublic

Description

Diffusion should get a modern diffusion.search endpoint.

Diffusion should also get a modern diffusion.edit endpoint, but that is probably like 2,000x harder because of the huge multipage form and all the workflow logic it entails, so maybe I just punt that for now.


Original Description

Our use case is that some repositories have special needs on the client side. We'd like to be able to create a special #project and tag it in Diffusion. For example, we have a custom arcanist workflow that takes special action before running 'arc land', but only on a specific set of repos. Similarly, we have use cases where CI needs to do some special checking depending on what is essentially a series of checkmarks per repo.
While some of this can be handled with Harbormaster and/or the new build work (T10329) going into arcanist, it remains generally useful to be able to see the metadata associated with a given repository.

This might be a special case of T5873 but I'm not sure

Event Timeline

eadler created this task.Feb 12 2016, 12:54 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

This will be supported by diffusion.search out of T5873. See also T10329.

eadler updated the task description. (Show Details)Feb 12 2016, 1:08 AM

right, I wasn't sure if it was a special case of either of those, but I figured I'd ask just in case.

Thanks!

(This is adjacent to T4245 and should be happening fairly soon -- next big-ticket item I'm currently planning to hit after subprojects/workboards calm down.)

I'm just going to co-opt this as a subtask for that piece since you already tagged it so nicely.

epriestley updated the task description. (Show Details)Feb 12 2016, 2:23 AM
epriestley renamed this task from Supporting custom fields for repositories and/or query projects for repositories and/or vice-versa to Implement `diffusion.search` and think about `diffusion.edit`.
epriestley moved this task from Backlog to vNext on the Diffusion board.Feb 16 2016, 9:44 PM
epriestley moved this task from vNext to v3 on the Diffusion board.Feb 16 2016, 9:51 PM
epriestley edited projects, added Diffusion (v3); removed Diffusion.

I just added about 100 staging repositories by hand. I hope I spelled everything right!

scode added a subscriber: scode.Feb 22 2016, 11:28 PM
avivey added a subscriber: avivey.EditedFeb 25 2016, 9:37 PM

Doesn't making an edit endpoint that is similar to the ApplicationEditor endpoint bypass the multi-page setup (And lets people shoot themselves if the foot)? RepositoryCreateController seems to be fully transactions-based now.

Yeah, that's broadly the "think about" part in the task title -- I don't have a good answer. I'm not quite sure how to reconcile diffusion.edit with the current multi-page form.

I'm currently leaning toward this:

  • Do T10366 first.
  • Replace the multi-page form with a single page form (pick a VCS, a name, and policies).
  • "Hosted" is sort of the implicit default, if you want to import you then add a remote URI and set it as a fetch URI.

I think that would map to diffusion.edit pretty well, but probably leave users a little lost on common flows (particularly, "import a GitHub repository") so we'd likely have to shore it up with some alternate "here's how you do this common thing" stuff in the UI.

Oh, there are also really two issues here, but only one that I think is actually hard:

  1. The multi-page repository creation form, where a single form has multiple pages in a cohesive workflow.
  2. The multiple small forms for editing all the other stuff a piece at a time.

I think dealing with (1) is probably hard, and the plan above would let us get rid of the multi-page workflow entirely, which is why I'm leaning toward it.

I don't have a plan for (2) either, but it's relatively easy. In the worst case, we just add all those fields (like "text encoding") as "Conduit Only" fields to the EditEngine, and leave them as separate workflows in the web UI. That's not great, but it would just cost a modest amount of code duplication, and we'd still be reducing overall duplication by a large amount.

I suspect we can do a little better than that, maybe by letting EditEngine have a concept of "sections", but the worst case isn't too bad so it's not a huge issue if we don't tackle that or don't tackle that for now.

I'm going to merge this into T10748, which has implemented these endpoints, although they won't be fully functional until we cut over to the new URI code, likely in the next week.