Feature Request: Option to count skipped jobs in has_successful_status

[stevoland]

GitHub branch protection rules and rulesets count skipped jobs as "success". Given GitHub's underpowered required checks config, this "feature" is commonly used with path filtering to avoid running unnecessary jobs in monorepos etc.

We also use policy-bot to ping reviewers directly when a PR is in a reviewable state (including minimum checks pass).

As has_successful_status only counts "success" state we have had to consider these workarounds:

1. Only policy-bot as the required check

The path filtering is moved to the policies - expensive jobs run unnecessarily

2. Duplicate the conditions in policy-bot

High risk of the filtering logic getting out-of-sync

3. Additional job (chosen)

Add an additional job that is dependent on the conditional jobs and fails if any of the conditional job results is not "success" or "skipped". This job is referenced in has_successful_status.

Small extra expense, some additional complexity and confusing PR check summary.

Thanks for your time!

[bluekeyes]

Thanks for the suggestion. I can think of several ways this could be added - are any of these preferable (or objectionable) for your usage?

• As an option on the rule (in the options block)
• As an option on the has_successful_status precondition
• As a server-level configuration (i.e. "skipped" is considered success for all policies evaluated by the server)

[stevoland]

From my perspective, the first 2 are equal. Server-level configuration is less good - it's possible that there are teams in our org replying on the current behaviour although I'm not aware of a specific use-case for that.

Let me know if you would rather we contribute the change once you have a suggested approach. Thanks!