Page MenuHomePhabricator

Create herald.queryrules conduit API method
Closed, WontfixPublic


Implement herald.queryrules Conduit API method. Method would allow user perform a search on Herald rules.

Event Timeline

Pawka claimed this task.
Pawka raised the priority of this task from to Normal.
Pawka updated the task description. (Show Details)
Pawka added projects: Herald, Conduit.
Pawka added a subscriber: Pawka.

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.


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.

Providing 1 for needConditionsAndActions and few additional parameters gives us pretty useful subset.

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?

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

You can parameterize the URL, in a build step, e.g.:${repository.callsign}

Is that not sufficient? How do the URLs vary?

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

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 could also add a custom field support for the token to Repositories, although this is probably some ways away.

Or we could make the build variables extensible, so ${repository.customtoken} would work.

Copying plans and Herald rules for each repository feels sketchy to me. I'm not interested in bringing herald.queryrules or similar upstream until there's a good use case for it (and/or we complete T5873), and this doesn't feel very good to me.

I see your point and sounds fair for me.