Abid H. Mujtaba

When I was developing PR #602 I realized that the user **must always** target `status.*` and **cannot** target specific status states such as `status.success` because `status` events do not have...

@samj1912 described a lot of the capabilities I was thinking of. Coupled with other validators and the available actions this will open up a lot of possibilities.

Agreed. This covers the use case I described. Thanks for the relevant changes.

This feature has been working really well where the base/target is the default (main/master) branch which is protected. However it is causing PRs between feature branches (where the base/target is...

For PRs that require long-running CI builds to pass we need to support `status.*` events in the `baseRef` validator because the last event that comes in is a success status...

@munkherdeneen, I have semi-recently updated my config to: ```yaml # Auto-merge PR when all required (in branch protection) checks have passed - when: pull_request_review.submitted, check_suite.completed name: 'All checks pass' validate:...

This might be the reason: https://stackoverflow.com/a/60576223/2926226

Same as @jbrwilkinson. This is fixed when buildkit is enabled globally: [docs](https://docs.docker.com/develop/develop-images/build_enhancements/#to-enable-buildkit-builds).

Possible MFE (minimum failing example): ```python from typing import Callable, ParamSpec P = ParamSpec("P") FunctionType = Callable[P, None] ``` ```console main.py:4: error: The first argument to Callable must be a...

@chrmarti, same firm as @EricHripko. Our frontend is designed to not require a `FROM` statement. It decides the base image to use based on the build context. Since this is...