Removing all of the *.search stuff and leaving the rest to make it easier on future diff archaeologists

Our actual internal use case is as follows:

@epriestley / @chad do you have pending comments on this? I can split it up into "obvious improvements", like bundling together search engine / dao / API methods per-dao. And then leave drydock.createlease and drydock.destroylease in their own diffs since I imagine they are the most contentious.

I may have misunderstood you, were you advocating for application capabilities instead of authorizations?

Edit engine is deceitfully magical, and you may have indeed done everything you needed to here.

From my perspective, it makes sense for it to be the user requesting authorization, for our use cases a user (or a bot user in the case of other services consuming this) should be the "thing" that is requesting authorization.

@epriestley couple thoughts:

fix lint problem

The bash workflow is just loaded the same way all of the other ssh workflows are loaded, I think that the problem is one of security policy / segmentation.

Maybe make it so that we can host an arbitrary number of ssh daemons on different ports with different entry scripts? I suppose we can kinda do that already by just copying the existing script, minus the part where we have different groups of ssh keys, but could probably sub in passphrase as the backing for authentication there.

Oh nice, I was expecting the "this is awful" upstream response for this :) I can put together use cases and either @jcox or I can work on upstreaming it.

In theory we could make it so that steps resume correctly, but in practice I have very little control over the contents of the scripts that get run. People tend to wrap all of the stuff up that their build is supposed to do into a single script, and assume they're starting fresh each time it's executed.

use pretty numbers when displaying build count

I'm not sure how this wasn't reported earlier, I guess the module cache prevented everyone from encountering it?

If you only knew how lucky you are to have Evan explain this to you rather than trolling through grep -Rn "PhutilClassMapQuery" * --include \*.php errday.

need some arc flow up in here

Live, armed, pre-commit A/B testing is unambiguously the most exciting part of our jobs.

Should we implement this as an internal search attachment in the meantime? Or is there a possible pathway for @jcox to get something like this working in ~3 days?

I'm thinking we just create a search attachment for maniphest.search which contains diff PHIDs.

Yes that would do it.

oh ok

Task ref? You should probably find the mechanism by which these are written and read, and test that rather than looking at SQL?

It relies on a server side API call so you'll have to actually extend your server install in order for it to work.

In T11518#191391, @chad wrote:

which devs don't? it's the designers, isn't it.

This is an ATC meme-ish at this point because I wrote so many controllers without page titles when I first starting extending Phab.

Basically "is the diff people are reviewing identical to your local branch"

Revision.

No I just read over all of the email commands and didn't see any exceptions thrown and I assumed this didn't work.

Playing devil's advocate, it's not too much of a stretch of the imagination to assume that one could then make it impossible to land things which have unaddressed "issues" vs "comments" on a review. That would be the only concrete advantage I see to explicitly defining these things rather than relying on human parsing.

@Ajaxs86 you appear to have posted your API token here and should probably revoke it.

This is always super confusing because "Revisions" start with a "D" in their monogram, but a "diff" literally begins with the letter D while a revision does not.

I dunno, @bjshively set it up, I was happy with the original :)

Gah, I knew I wasn't supposed to do that, short array syntax is wired into my brain unfortunately. I'll fix them up.

Return a dictionary for the build status over conduit.

I do have plans to implement arc builds...