(@amckinley, if you have time to pick this up it's one of the more tackle-able tasks in the support queue.)

I'm going to call this effectively resolved:

The page implies that all I should need to do is POST up, for example, the following:

Can you point me at where that's implied so I can make it more clear? That isn't currently expected to work. ... We do not currently support a blob of JSON as the post body, and the documentation shouldn't imply that we do (if it does, I'll fix it).

Parsing hg export metadata is an elegant solution. # HG changeset patch could imply sourceControlSystem = 'hg'. Thanks for merging the task!

Ahhh, that makes more sense. I parsed that as saying "we could migrate the code" instead of the saved objects. If you want to add the glue code now and then assign it back to me after, I'll work on the migration in my Copious Free Time™.

Oh, sorry, maybe I wasn't clear. My plan is this:

If you're happy long-term with accepting all three types, I'm ok with that as a permanent fix. I'm planning on working through this week, just with weird/inconsistent hours.

Yes, we could migrate these instead.

Are saved queries/EditEngine forms things we could write migrations for? That might be even more brittle (for example, what to do about saved queries for priorities that no longer exist on the install), but accepting three different priority specifications of two different types seems a little too Postel's Principle for me.

I'll see if I can smooth this over a little before installs figure it out.

After some additional poking, there are a couple of other compatibility issues here:

Milestones works great for this, but you still have to manually create the workboard (just going into workboard and clicking create - milestones show up).

We also technically do something like this in the production cluster today with bin/services sync, which (among other things) synchronizes Almanac services from the admin tier. The script currently just cheats and forces them to allocate with the same PHIDs, so we know local service X is the same as remote service X because they have the same PHID. I'm not sure we'd necessarily change this if we had a real "utilities" API but it's definitely a bit hacky as written today.

That does sound powerful. +1

Maybe another capability here is just letting callers put a random bag of properties on any object. I don't reaaaaally have use cases for that but it "seems powerful" if we're building all of this already at some point.

Okay thanks for your answer. So if i used audit.Query to get (for example) audit statuses etc.. I have to wait that diffusion.commit.search implements all functionnalities?

No.

Is it possible to unfreeze audit.query if diffusion.commit.search is not returning enough informations to replace audit.Query?

Thanks! Will check.

@aurelijus, D18111 is landed now in HEAD if you'd like to test this. Let us know if you have any issues.

I have spent a little time poking at code, trying to figure out how to build a simple template engine into the description field, so that you can reference hidden custom fields by {field-identifier} or similar from within the remarkup. I resigned myself to building something just like publish.php, where the descriptions are maintained via conduit, however, I still long for it to be built in.

We actually do this ourselves in the "Locations" technical interview scenario: the script tries to create a set of tasks, or update them if they already exist. It currently uses title-based search to accomplish this, but could more reliably use "utility labels" if they existed.

We do something similar ourselves for technical interviews, but I just related all the tasks by embedding them in the description of a central task:

This sounds REALLY useful. Relatedly, it would be useful if I could auto-generate a task for each recurrence of an event.

With only those fields:

{
  "data": [
    {
      "name": "Open",
      "value": "open",
      "special": "default",
      "closed": false
    },
    {
      "name": "Resolved",
      "value": "resolved",
      "special": "closed",
      "closed": true
    },
    {
      "name": "Wontfix",
      "value": "wontfix",
      "closed": true
    },
    {
      "name": "Invalid",
      "value": "invalid",
      "closed": true
    },
    {
      "name": "Duplicate",
      "value": "duplicate",
      "special": "duplicate",
      "closed": true
    },
    {
      "name": "Spite",
      "value": "spite",
      "closed": true
    }
  ]
}

Maybe just include name, value, closed and special?

Similar example for new maniphest.status.search. I'm happy to drop any of these fields if you think we won't need them (prefixes and suffixes leap to mind).

(In this case, our behavior was strictly wrong, completely accidental, and trivial to fix -- but sooner or later we may make some kind of change which isn't very compatible with this older style of integration in a more fundamental way. When we do, a blog post from 2013 suggesting a set of workarounds at the time won't hold back the tides of change.)

The general story on Build/CI is this:

In T12766#225295, @epriestley wrote:

Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯

Thanks, everybody! Appreciate it, especially on a Friday night. :-)

Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯

Note also that differential.revision.edit accepts IDs and harbormaster.createartifact allows you to create links to build results without needing to gum up the feed with comments. We will eventually remove differential.createcomment so things will need to update sooner or later.

This should be fixed in HEAD of master and stable. Thanks for the report!

That does indeed work! Thank you so much!

Does this work?

Not easily. :/

Can you use the modern conduit calls?

That looks great to me.

Actual example output:

Yeah, with whatever wrapping context maniphest.search has, so like:

So should the return value for priority.search look something like this?

That is, the specific error "use lists" is aimed at preventing is this:

The config also looks like this right now:

I guess we already have "keywords" and should probably accept any of them, too, so "!priority high" in mail, /priority high in a comment, and "high" in Conduit all work consistently even if the actual key is "elevated".

Ideally, we should maybe freeze maniphest.querystatuses (which has a sort of ridiculous output format, I think?) and provide maniphest.status.search and maniphest.priority.search, which return results similar to other modern *.search methods even if they aren't implemented quite the same way (at least make the output format similar enough that a client library with methods like "turn a x.search call into a list of objects" would work on these methods, too).

It looks like what we really need is a new method like maniphest.querystatuses, called maniphest.querypriorities to avoid anyone trying to hardcode these values.

Yes. We'd retain the base revision information during parsing in differential.createrawdiff, and it would remain available later in arc patch.

@epriestley - Just to clarify, with the solution you're suggesting that would mean the diff created using differential.createrawdiff → differential.revision.edit would result in arc patch of that revision applying the patch to the base revision parsed from the raw diff from hg log --patch --rev <rev>?

Thanks, I'll just keep an eye on this ticket and switch whenever I need to.

Right, you can't user.search for the currently logged-in viewer. If you don't need to know this (you already know the right username or PHID) and were just using user.whoami for convenience you could switch today, but, e.g., in arc we rely on identifying the logged-in viewer with a Conduit call.

I assume based on your comment there isn't a good replacement for whoami until viewer is available on search? (aka I'll keep using whoami until viewer is available as an input to search)

Oh, you're right. I misread an implication of implementation specifics into "set", but the actual language doesn't actually suggest an implementation.

I tried to not specifically ask for a change to API or parsing, just that the missing bit I need is a base revision set on the new diff.

A maybe-less-complicated approach here could be:

For those looking for how to associate tasks to columns - reference the following from T12074:

We've run into this a couple of times. When a user updates a revision through the web UI, the repository field (at /differential/revision/update/{REVID}/) doesn't auto-populate with the revision's repository and people sometimes forget to fill it out. This causes the repository to be stripped from the revision as well.

This is now possible with edge.search.

Use diffusion.repository.search or phid.lookup to map repository identifiers to PHIDs.

We don't have any way to move forward here.

In T12447#216806, @epriestley wrote:

But if you say "Haskell" you may have to wait a minute.

Raw HTTP is actually perfect for me! Thank you!

But if you say "Haskell" you may have to wait a minute.

Maybe easier would be for you to tell me what language you want to use and I'll just write you a snippet which encodes a request?

The page implies that all I should need to do is POST up, for example, the following:

To be clear though, I still haven't figured out how to actually put in a POST body. It's fine to use URL params for something like differential.querydiffs, but I can imagine the problems I'll run into with URL length when doing harbormaster.sendmessage (especially when reporting a bunch of unit test and linting results).