This use case is obsoleted by Harbormaster (T1049).

FWIW, it looks like arc export hits this when invoked with --diff-id DXXX instead of --diff-id XXX

I see your point and sounds fair for me.

Can you make a single call to some kind of middleware which looks up the token based on the callsign or ID, then submits the request to the build server?

We are providing different tokens for each URL.
And this parameter is not stored on Phabricator :-(

You can parameterize the URL, in a build step, e.g.:

Each rule has different parameters in steps. In our case it is different HTTP Request URL.

What kind of rules are you duplicating across repositories? Why can't these rules be expressed as a single rule which affects all the repositories?

We trying to automate Harbormaster + Herald setup for new repositories in our company (have plans to provide Harbormaster API methods soon). This method is required to check if specific rules are not created yet.

Can you walk me through your use case in more detail? We've never seen interest in this, and I can't come up with reasons why this would be useful offhand.

Specifically, submitting ids: [[1]] will reproduce this:

I think we can only fix this by adding typechecking to Conduit, which will happen some day but is a larger project.

This was fixed by D11102.

Thanks Avivey,

After checking with my team, the main need is to assign automatically the review to a specific team member because we know who will review the commits before coding.That's why we create a rule for each evolution to assign automatically the review to the right person.

T3670 will provide a cleaner and more general solution by letting you write one rule against the superproject (like #client) and have it automatically apply to subprojects.

Oops, I'm sorry. I'll try to explain better what my team and I are trying to do :

This report describes a solution instead of a problem. When filing a feature request, please describe the problem you're facing, not just your desired solution.

Particularly after strengthening the "prototype" barrier, this is more of a "users want it" issue than a "this has high support costs" issue.

The utf8 stuff hasn't been coming up much; the token-based stuff is just blocked on docs and also hasn't come up much; I touched the protocol enough that I'm pretty confident we can move forward without backward compatibility breaks.

In ManiphestTransaction::getActionName, why is TYPE_TITLE the case with the if ($old === null) return pht('Created'); check, instead of TYPE_STATUS?

At least for now, this no longer blocks Phacility or T2783.

T2783 is at least partially blocked on this, since I need to make intra-cluster calls as the viewing user and don't want to do handshakes. I also don't really want to ship session keys across in the raw, although that wouldn't be the end of the world. I'll probably push this about halfway forward and then drop it again once T2783 is unblocked.

This is effectively working now. Some followup work in T5955 and T6706.

I'm currently making the Phacility deployment tools load all Almanac services and filter them on the client to generate a list of instances hosted on a given machine (e.g., all instances with storage on db001). This is super gross:

Adding SSH keys currently requires MFA in all cases, so we'll have to figure out what the rules are here.

We unfortunately cannot provide support at this time for writing applications. We recommend using IRC and discussing questions with other Phabricator developers. irc.freenode.net #phabricator

Depends entirely what "Other Tools" means. Conduit and Doorkeeper will be built in means of talking to external systems. Remarkup can certainly be expanding to offer more flexibility in writing content into Phabricator. Custom Fields and Event Listeners also allow for customization. Forking and maintaining patches are also what we recommend to people who need heavy integration/customization.

Yes, for the base problem.