Task creation slightly ahead of HEAD through maniphest.edit now hit essentially the exact same code as the web UI, and no longer appear to do this "[Reopened]" stuff.

We haven't seen other use cases for this. OAuth or Nuance are more likely approaches from an upstream viewpoint.

My stacktrace:

Never mind, this was straightforward to reproduce:

Do you have a stack trace in the error log offhand? I can't immediately reproduce this on this install after upgrading. I have a good idea what's going on, but if you have a stack handy that might be faster.

This install is just a little out of date, second issue should be fixed at HEAD.

(I'm pretty sure this is us, but want to be sure)

Yes, of course. I apologise. We updated to head today.

@mikn The question remains, what version of Phabricator are you on. This install is not kept at HEAD.

The repro case is against this install. :)

Is your server up-to-date? What versions is it running? https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#update-phabricator

In T9766#144249, @eadler wrote:

A somewhat generic way to do this is to create the notion of a variable such as is_in_deployment and allow Herald rules to check to see if this is set/true/a specific value. If the API to expose the variable is exposed to conduit then also allows for far more interesting workflows (especially when combined with relying on other Herald rules).

A somewhat generic way to do this is to create the notion of a variable such as is_in_deployment and allow Herald rules to check to see if this is set/true/a specific value. If the API to expose the variable is exposed to conduit then also allows for far more interesting workflows (especially when combined with relying on other Herald rules).

@epriestley correct.. basically we have an external system (a Jenkins-like CI tool) that we're effectively using as a workflow engine. The timing isn't strictly defined, it's basically "when the user presses the button, do all these things".

Just to clarify, you would rather rely on an external script to activate and deactivate this rule every day instead of having a Herald condition like "Current time is between 5PM and 9AM"?

As a minor technical point, you're trying to create imported repositories (i.e., import repositories from GitHub), not hosted repositories, right? This endpoint can't create hosted repositories at all, AFAIK.

This endpoint is very old and has a lot of problems, including not being cluster-aware. In the Phacility cluster, the web host and repository hosts are separated. repository.create can not create cluster-aware repositories.

FWIW, my intended use case is to consume GitHub's organizations feed and automatically mirror repositories in Phabricator.

Yes, that works! It looks like it takes an object of one of these forms PHID-DREV-xxxx (a revision), PHID-DIFF-xxxx (a specific diff in that revision), or a PHID-HMBB-xxxx (a buildable).

Try the diff PHID -- $diff->getPHID()?

Thanks, in the last option, what kind of thing should I pass into harbormaster.queryautotargets for the objectPHID? If I leave it blank I get

{"result":null,"error_code":"ERR-CONDUIT-CORE","error_info":"No such object \"\" exists."}

My request was

{
  "targetKeys": [
    "arcanist.unit"
  ]
}

It looks like that code isn't interacting with Harbormaster at all and is making an HTTP request to Changes directly from inside a Herald action. We (fairly strongly) discourage this as a way to communicate with external systems (see T5462 for discussion/rationale -- it's synchronous and blocks the UI, error handling can't happen properly, and there's no way to retry if it fails). There is no build target available during the execution of Herald actions and I can't really come up with a reasonable way to generate one.

Thanks -- it's hugely helpful to know that Phabricator already merges coverage!

It's supposed to be sent with the call to the external build system, but that doesn't seem to work either -- the build target phid received is always ''.

I'd recommend looking at exactly what arc does and following that, rather than trying to construct calls from scratch.

I am writing a git module to create revisions from git, it is quite similar to arc but I want to avoid rewriting commit messages (Summary and things like that), have a better integration with git and allow sending branches without squashing the commits.

Why are you trying to create revisions with a direct API call? Can you describe the broader problem you're facing? There may be a better solution. See:

Meaning I get the same error while being close to master.

In T9536#139667, @avivey wrote:

I can re-create this near HEAD.

I can re-create this near HEAD.

In T9536#139625, @avivey wrote:

why is there a '\'' before originalTitle in your json? And why are you manually setting originalTitle anyway?

why is there a '\'' before originalTitle in your json? And why are you manually setting originalTitle anyway?

I see, how could I set the Diff repository (can't find a way to do that in the UI) or actually get the revision repository from conduit?

For some reason that I don't know offhand (maybe historic reasons, maybe just an error), this method returns the repository PHID of the active diff instead of the repository PHID of the revision itself.

You can't add Conduit tokens without MFA though right?

If users have MFA configured, I think it's important that we not let an attacker avoid MFA checks on operations (including adding SSH keys) by using Conduit. So if we had a method for adding SSH keys we'd either have to deactivate it when we hit an MFA block, or implement CLI MFA somehow (seems tricky/complex?) or have it add a "request" and then require the user to confirm that they want to add the key via MFA from the web UI after passing MFA, maybe (this feels bad to me for a bunch of reasons, though).

It would be easier to implement this if we say the second form is required (enter JSON -> parse JSON -> interpolate the variable in stirings), but I think it's not intuitive that you can't just type {$me.phid} into a field like authorPHID. Certainly, I'd expect that if the console supported variables they'd be proper-value-variables, not string-interpolation-variables, since string interpolation is completely useless except that it's easier to implement.

In T8975#138256, @epriestley wrote:

We haven't seen other requests for this and I don't think it's very straightforward. Consider these JSON values:

[{$me.phid}]
["{$me.phid}"]

The former value is not valid JSON though?

There are two use-cases here:

We're already impersonating them; we do the standard arc install-certificate process to configure Arcanist, and then we want to automatically configure SSH access afterwards. This is to make configuration of a developer's machine only require one manual step (authenticating with Phabricator for Arcanist).

Aha, so the users are also different, and they're real users (not bots)?

Because they're developer machines VMs, we want pushes to be recognized as that developer, so they have the correct policies applied.

I don't understand this use case. Why do you have unique keys per-VM?

We haven't seen other requests for this and I don't think it's very straightforward. Consider these JSON values:

Awesome. Thank you! ?

I think @epriestley misunderstood what the bug report tried to address. I ran into the same problem yesterday.