Can you describe the root problem? What kind of rules are these? Revision rules?

I'm generally not excited about adding variables (or flow control constructs, etc) to Herald and would like to see if we can find another approach.

Minimally, you can write a custom action like:

When:
[ Always ]
Take Actions:
[ Subscribe any repository projects listed in Paste: ][ Pxxx ]

Then you create a Paste like "Master list of projects which auto-subscribe when revisions associated with a corresponding repository are created" and dump a list of all "X, Y, Z" in there.

Basically, use Herald as a callback and Paste as a config file, and put the actual logic in custom code.

In T10623#165958, @epriestley wrote:

Can you describe the root problem? What kind of rules are these? Revision rules?

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in. As this list grows it is getting unwieldy to figure out which projects are configured this way.

I'm generally not excited about adding variables (or flow control constructs, etc) to Herald and would like to see if we can find another approach.

Minimally, you can write a custom action like:

Basically, use Herald as a callback and Paste as a config file, and put the actual logic in custom code.

We don't have any custom logic. We just have a significant amount of duplicated logic.

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in.

Would something like adding "Watch Repository", like "Watch Project", so users could get CC'd on every commit and revision for a given repository possibly be a better solution for this?

We don't have any custom logic.

Oh, sorry, I'm not suggesting you do. I just mean that writing custom logic might be a better approach to this kind of problem than trying to make Herald into a substantially more powerful computation engine (with variables, or, in other cases, control flow) so it can express this logic natively.

This logic takes about 15 minutes to deduplicate with a custom HeraldAction, but implementing variables into Herald is probably more like 10-20 hours of work, conservatively.

From a pure cost point of view, asking us to write this logic for you costs about $375 at consulting rates, while asking us to build Herald variables is $3,000+ at prioritization rates. Maybe that's worth it if you have a large number of different use cases, and can convince us this is worth maintaining, but I'd guess the calculus probably doesn't work out.

In general, I expect installs to mostly handle complex cases by extending Herald with custom code, not by implementing variables, logic, reentrancy, web hooks, lint engines, control flow, counters, statefulness, etc., into Herald in the upstream.

In T10623#166012, @epriestley wrote:

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in.

Would something like adding "Watch Repository", like "Watch Project", so users could get CC'd on every commit and revision for a given repository possibly be a better solution for this?

Probably not. Sometimes the "if condition" is more granular. We'll make do with what we have for now. It isn't impossible, just unwieldy.

T1258 might be another attack on this, not sure how much that overlaps things.

Or T10622 (prefilling subscribers instead of reviewers), if this being client-side / advisory / user-editable is OK/desirable.