Like just don't show it at all? That seems reasonable to me, although 0.00000000001 is very funny and we would be losing a truly great joke at such a young age.

maybe herald adding a subscriber is truly 0 then as a feed story.

That's because it was deliberate self-subscribe which is so completely boring that we normally wouldn't even show it. I think it's arguably correct to show the Herald story? Maybe?

This is an emergency.

Deliberate Subscriber + Herald Subscriber = Herald Subscriber Story.

very nice

seems ok to me.

I think that story strength thing is non-retroactive? This may not really be fixed if new stories aren't better.

There's some level of magical heuristic, so yell if you still see issues.

From T10822, we currently choose [Changed Subscribers] as a stronger action than [Merged] for tasks in some cases in email subject lines. This is probably not the correct heuristic, [Merged] is normally a strong action.

Interesting. Time to update my bot. Thanks!

See also T5462

I have build kind of thing out myself, using polling to check what revisions are open, then diff my list of "envs / build jobs" that I have running and then make the two line up. It would nice if it could be event based and triggered by herald.

Awesome! Thanks for the quick reply @epriestley :)

See T5726, T10363.

The data available from feed.http-hooks or feed.query is somewhat limited:

I think this should be fixed in HEAD, let us know if you're still seeing it after updating. Thanks for the report!

@chad False alarm, I've checked wrong link. Problem existed on Maniphest global rules but it seems it is fixed already on upstream.

I'm still able to select stuff fine and use the form, did you try the dropdown? (I do see the error in the console).

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

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?

Understood. Thanks for the information.

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.

In T10623#165958, @epriestley wrote:

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

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

Maybe a good idea too:

• What about if you can configure at owners, if the owners should added as (blocking) reviewers automatically? Makes this simple too.

Thanks for all the examples - definitely makes sense that these behaviors are a bit of a different class than ones that actually examine file content.

is there a way to add subscribers via lint rules?

I suppose the rules I am writing are fairly lint-like; part of this
reflects the sorry state of our lint infrastructure, though it is probably
a bit more flexible than herald. Having said that, sometimes I do want to
have rules that subscribe me to various diffs, before I figure out how to
automate my own advice; is there a way to add subscribers via lint rules?

Primarily, I'm just hesitant to make changes where you upgrade and previously-private stuff becomes public, since I think that's a terrifying behavior in the general case and maybe even worse than destroying data.

To provide a little context, I suspect we'll just make personal rules publicly visible. Long ago, transaction records were not as explicit or complete as they are today and you could sort of hide your "keep an eye on the suspicious interns" rules a little better, so this policy behavior wasn't totally silly, but it's almost impossible to actually hide any information now.

Is this rule a lint-like rule, in the vein of T7617? See also T10523 for discussion of lint-like rules.

Ok so I just took it for a spin while editing herald rules. While it sort of solves my problems, it's very much a poor-man's solution - it's completely out of the way from the "create a herald rule" workflow - ideally, on the page where I'm creating or editing a herald rule, the test console should be right there so I can try out my new rule without necessarily having to save it; also it would filter to just trying that rule instead of trying all the rules, which would cut down on visual noise. This sort of change would make it much easier for the non-power user to create working herald rules.

Sounds good. I'm going to close this out since we don't plan to pursue the particular rule it describes and I think other related work is already covered elsewhere.

You may be able to moot this issue by removing the copyright headers entirely.

I believe this wouldn't solve your problem: I could add two files, A.c and B.c, and add a header to only one. This would pass the rule but fail what you intend to enforce, I think.

Not sure if related to this task or not, but I'd love the ability to have Herald rules act on countdowns. Sometimes we have tasks that fan out to many teams and we'd like the ability to assign it to the team, but add a project or change assignee once a countdown expires.

There is no way to be alerted to blocked pushes right now, and I generally don't think this is useful enough to include in the upstream. This interaction could possibly be more clear, but feels like something we just stick in the documentation to me.

This gets a brief mention in the documentation, but generally:

Derp. I'll check it out.

what test console?

Have you tried the test console?

Ok thank you for these precious answers, I'm going to start this way.

Yeah -- you're actually going to extend HeraldField. A good place to start might be DiffusionPreCommitRefPusherProjectsHeraldField. Basically:

Ok, thank you for your answer.
One last thing, is it possible to implement custom conditions as it is for custom actions? I haven't read about this anywhere.

If you want to block a push when a user has too many open reviews, you need to write a new condition, not a new action. Your rule will look like this:

Sorry for that, I added it at the beginning. We'd like to try to make people do their code reviews more often, and not let them pile up while writing some new features.