Page MenuHomePhabricator

Herald template / recipe book / examples / quick-create tool
Open, Needs TriagePublic

Description

Often people show up in IRC and ask how to create a herald rule to block unaccepted revisions, except they don't know any of the right terms.

There are a few more often-repeating Herald rules:

  • Anything in Owners
  • Forbid dangerous pushes there's a button for this in repo edit screen
  • Prevent dangerous pushes unless it's [me]
  • [email] me about any change to [this file]

We should have a bunch of templates (Hard coded, for start) that are less daunting for users to start with than the herald console (And maybe easier to find?)

Related Objects

Event Timeline

avivey raised the priority of this task from to Needs Triage.
avivey updated the task description. (Show Details)
avivey added a subscriber: avivey.

See also some discussion in T7804.

(I lean toward "Recipe Book" instead of "Quick Create".)

avivey renamed this task from Herald template / examples / quick-create tool to Herald template / recipe book / examples / quick-create tool.Jun 24 2015, 10:06 PM

T8682 describes another recipe, if [body][does not contain]['magic word'], [block commit] to let you create warnings/prompts when committing.

eadler added a project: Restricted Project.Sep 15 2016, 6:10 PM

From T11878, these patterns aren't obvious:

  • Write condition "(A and B) or C" by writing these rules:
    • Rule X: When all of: condition A, condition B; do nothing.
    • Rule Y: When any of: rule X, condition C; do stuff.
  • Write "state A transitions to state B, being in state B does something" by writing these rules:
    • Rule X: When all of: object is in state A; move to state B.
    • Rule Y: When any of: rule X, object is in state B; do something.

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." ]

See PHI242. SR Latch:

Set the latch:

When:
[ State is X ]
[ Flag Y is not set ]
Take actions:
[ Set flag Y ]
[ Cause side effect ]

Reset the latch:

When:
[ State is not X ]
Take actions:
[ Unset flag Y ]

This attempts to cause some side effect (send an email, add a comment, fire webhook) only when an object changes into a particular state, then stop sending email while the object remains in that state, then send another email if the object leaves and returns to that state later.

Today, the "flag" probably needs to be implemented with a dummy subscriber or a custom field. T12799 might add more options eventually. This use-case is wildly off-label.

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

When:
[ Commit uses Git LFS ] [ is true ]
[ Repository ] [ is not ] [ List of Repositories where LFS is Allowed ]
Take actions:
[ Block commit with message ] [ "Git LFS is not allowed in this repository." ]

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

When
[ Change is enormous ] [ is true ]
Take actions:
[ Block commit with message ][ "This change is too large to be processed." ]

"Change is enormous" means we can not execute Herald rules on it because the diff text doesn't fit in memory (currently, more than 1GB of diff text or more than 15 minutes to pull the change out of the VCS).

We should probably make this a repository-level, default-off setting like "Allow Dangerous Changes" since this is currently something of an attack vector. For example, you can sneak LFS changes past the rule above (if it is acting alone) if you do this:

  • Add an LFS object.
  • Add a 1.5GB text file.
  • Push the commit.

Herald will currently give up on processing this commit, so it won't be blocked by commit rules.

At least in theory, this isn't an especially realistic attack vector because an attacker needs to make a lot of "noise" to exploit it, but our defaults should be set up better. I'll file something specific about this.

epriestley moved this task from Future to Guidance on the Herald board.

See PHI612 and elsewhere; using "Take action [the first time this rule matches]" isn't always obvious but is usually a better fit than "When [ thing is created ]" and interacts much better with drafts.