You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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!
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!
The text was updated successfully, but these errors were encountered: