The fix for T13031 may have made this worse by default, since we now extract all pushed changesets and hold them in memory by default, even if no Herald content-based rules which use them actually exist. This may create too much memory pressure if you push a very large number of commits.

Adjacently, some other parts of the UI currently use the word "enormous" (see https://discourse.phabricator-community.org/t/herald-enormous-check/822). They should be rewritten to use different language (like "Very Large"). We should use the term "Enormous" to mean only "too large to process completely", while the other UI uses it to mean "large enough to partially collapse for viewer convenience".

Also, while it's on my mind, all repositories should probably have this rule today:

See T7789 and D18827. Block Git LFS in some repositories:

See PHI242. SR Latch:

I'm unable to close this, but I believe this to be resolved (or at least my specific repro of flags via herald no longer applies I believe).

Ah, thanks. I think your guess is right. I'll make a note in T2543, should be a one-line fix I think.

From https://discourse.phabricator-community.org/t/644 - it appears that HM now triggers a build on revisions when they are closed via landing, which fails because the build expects a Staging ref. I don't have the setup to test any of it, but the latest revision landed here doesn't show the behavior, so either f7f3dd5b2084 hasn't rolled in here yet, or that user is doing something funny.

oh, nice work, it will trigger parent task as well when subtask changed, seems I need to add the "condition" like subtask status instead of a "action" for this... any samples? Thanks!

Question: When subtask was fixed, the parent task want to have a action, for example, add a tag or change status if all subtasks were fixed.
So how to get this work in the extention of herald action? Thanks in advance!~

The best place for this kind of question is now your organization's support pact -- @tammybutow or @alexmv should be able to help you get access.

@epriestley so maybe this isn't the right place to leave this comment (let me know if I should create a new task?) but I'm finding this is acting in a way that seems a bit inconsistent. In particular, I added a new boolean custom field --

Herald rules are now always public, which possibly addresses the original issue.

oh thanks!

I don't think this is resolved, just an unclear report. To access this screen:

Methinks that the Rube Goldberg solution for this would be to get unittest.skip to have another argument with a task number, and then validate with lint/runtime that it look like T1234. And then maybe grep the body of the ticket for the filename.

Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?

That is, I think the right tool for the job is either runtime enforcement or lint enforcement: make unittest.skip() with no reason fail (so the tests don't pass) or make lint raise a warning like "unittest.skip() must have a comment above it explaining the plan for re-enabling the test.".

Can you change the syntax to something like @unittest.skip("Reasoning behind this decision...")?

I know about T9853, but if there's still a chance you might consider merging that upstream, there are a few folks here at Khan Academy who are excited by the feature. Here's one example:

Yeah, I'm pretty pessimistic about the security of SMS (or voice) as a factor. See also T7639 and T6549#97130. The article identifies these vectors:

https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/

Thanks :)

From T12771:

Global Rule for Differential Diffs
When:
[ Repository ] [ does not exist ]
Take these actions:
[ Block diff with message ] [ "Repository unrecognized. See https://helpful-docs.com/repository-help for details." ]

We have lots of APIs for external things, but without knowing what you're trying to do specifically, we can't really give you advice here. Herald / Mail are absolutely never the correct answer. Doorkeeper, Harbormaster, Feed Hooks, all available out of the box.

For now I have a ugly idea: Change content in PhabricatorMailImplementationPHPMailerAdapter.php and add some lines to invoke another python class of my own.

Hmm ok. I think that I'm not usually listed explicitly as a reviewer, which means that Reviewers: #some_project_that_i_am_a_member_of doesn't include me. Would you be in favor of adding a new [Differential was reviewed by] field to Herald?

I don't think this behavior has changed. This has always meant "reviewers", not "reviewers who accepted the revision".

Thanks for the report! This should be fixed in HEAD of master, and promote to stable tomorrow, a little more than 24 hours from now. Let us know if you run into any issues.

Thanks for the report! This should be fixed in HEAD of master, and promote to stable tomorrow, a little more than 24 hours from now. Let us know if you run into any issues.

D17221 adds an "Auditors" field to Herald.

• H140
• {H140}
• H141
• H141 force chad

T11953 isn't exactly the same as this, although they're similar.

From T11878, these patterns aren't obvious:

Nuance is our plan for routing tasks, we don't anticipate needing this functionality in Herald.

Ok, read that. Here is a breakdown of our wishes and what we did to implement them:

Please read and follow Contributing Feature Requests.