PullApprove expressions allow you to write powerful, custom rules to design your workflow.
Expressions are evaluated in a Python environment, using the provided functions and variables. You can use human-readable operators like "in", "not in", "and", and, "or".
Single vs multi-line
Most basic expressions can be written in a single line. In YAML, you'll typically want to surround these with quotes since you'll have quotes inside.
version: 3 groups: security: conditions: - '"security" in labels'
When you're comparing lots of values, it may be easier to write the expression over multiple lines.
version: 3 pullapprove_conditions: - > contains_any_fnmatches(files, [ "packages/*", "apps/*", "docs/*", ])
You can apply the same basic operations to most of the data we make available. Here are some common examples of how to use the available functions and variables.
Basic string comparisons will use fnmatch under the hood.
"*.js" in files or "frontend/*" in files
You can also use the
contains_any_fnmatch function to check more paths at once without writing lots of "or" lines.
contains_any_fnmatches(files, [ "packages/*", "apps/*", "docs/*", ])
contains_any_globs(files, [ "packages/animations/**", "packages/platform-browser/animations/**", "aio/content/guide/animations.md", "aio/content/examples/animations/**", "aio/content/images/guide/animations/**", "aio/content/guide/complex-animation-sequences.md", "aio/content/guide/reusable-animations.md", "aio/content/guide/route-animations.md", "aio/content/guide/transition-and-triggers.md", ])
glob("packages/**/*.js") in files
You can also chain the
exclude methods to further filter down a list of files:
head branch variables.
base.ref == "master"
base.ref != base.repo.default_branch
"feature" in head.ref
"bug" in labels
"sig-*" in labels
regex('.*/app') in labels
Other PullApprove groups
Use the state of preceding groups (above the current group in your config).
len(groups.approved) > 3
"admins" in groups.passing
Checks and statuses
The GitHub interface often combines these, making it hard to tell the difference.
The best way to tell the difference is to look for the Checks tab on a PR page.
For anything on that page (like GitHub Actions/Workflows), use the
If you have a status that is not on that page, it will be found in
"build" not in check_runs.failed
"*travis*" in statuses.succeeded
PR body or title
"WIP" in title
regex("WIP: .*") in title
"needs review" in body
changed_files > 30
author in ["internA", "internB"]
author_association == "FIRST_TIME_CONTRIBUTOR"
Git diff and files changed
created_at < date('3 days ago')