DEV Community

Cover image for GitHub Required Checks Are Static. Your Pull Requests Aren't
Marcus Vinicius Tavares
Marcus Vinicius Tavares

Posted on • Originally published at blog.mergeguard.dev

GitHub Required Checks Are Static. Your Pull Requests Aren't

GitHub Required Checks Are Static. Your Pull Requests Aren't

A docs-only pull request should not have to wait for backend builds, integration suites, and security scans that were never relevant to the change.

But a lot of teams still live with exactly that.

Why?

Because GitHub required checks are usually static, while pull requests are not.

That mismatch creates a common set of bad options:

  • require everything and waste CI
  • require less and weaken protection
  • or fake conditional enforcement inside workflows

The last pattern is especially common.

Teams keep a workflow required for branch protection, then use path filters or changed-files logic so the jobs exit quickly when the change is irrelevant.

That workaround is understandable.

It is also a sign that workflow execution is carrying policy decisions it was never meant to own.

The distinction that matters

There are really two different questions:

  1. Should this workflow run?
  2. Should this check be required for merge?

Path filtering helps with the first one.

It does not answer the second one.

That is why a scoped workflow like this is useful but incomplete:

on:
  pull_request:
    paths:
      - "api/**"
      - "db/**"
      - "auth/**"
Enter fullscreen mode Exit fullscreen mode

This is good execution logic. A backend workflow should not run for a docs-only change.

But branch protection still needs to know whether backend checks were required for this pull request in the first place.

That is the real gap.

Conditional execution is not the same as conditional merge requirements.

For example, a docs-only PR may need only docs linting, while a PR touching api/, db/, and auth/ may need backend tests, integration checks, and stricter approvals.

What a better model looks like

The cleaner approach is to separate execution from policy.

Let CI answer:

  • what ran
  • what passed
  • what failed

Let policy answer:

  • what needed to run
  • what approvals were required
  • whether the pull request is merge-ready

That makes pull request behavior much easier to reason about.

A docs-only change can require lightweight checks.

A pull request touching api/, db/, and auth/ can require heavier tests and stricter approvals.

Same repo. Same protected branch. Different pull request. Different required checks.

That should feel normal.

Without a policy layer, teams usually end up in one of two bad states.

Either they require everything and accept wasted CI, or they stop requiring checks they do not know how to model cleanly and accept weaker protection.

Neither is a great long-term answer.

The annoying middle ground is even more common: keep the workflow required, let it start on every PR, and add enough shell logic that it can pretend to be conditional.

That works, but it also turns CI YAML into a place where merge policy quietly accumulates.

A concrete example

Imagine two pull requests in the same repo.

The first changes only docs/ and README.md.

The second changes api/, db/, and auth/.

Those pull requests should not need the same merge requirements.

The first might need docs linting and a quick approval path.

The second might need backend tests, integration checks, and stricter review.

Same branch. Same repository. Different pull request. Different required checks.

That is the behavior teams usually want, even if GitHub’s native required-check model does not express it cleanly.

Why one required policy status is simpler

This is why the “single required MergeGuard status” model is appealing.

Instead of forcing every possible workflow to show up on every pull request, GitHub can require one deterministic decision about what this pull request actually needs.

MergeGuard evaluates PR context and decides:

  • which checks matter
  • which approvals matter
  • whether merge is allowed

Your workflows stay focused on execution. The policy layer handles merge logic.

That can reduce wasted CI time, but it also improves the design:

  • less branch protection churn
  • less policy logic buried in YAML
  • clearer merge readiness
  • stricter protection without forcing irrelevant workflows to run

It also makes the pull request easier to explain.

Instead of asking engineers to infer merge readiness from a changing set of workflow outcomes, you give GitHub one deterministic answer about whether this PR has satisfied the checks and approvals that matter.

Closing

Path filters and changed-files actions are still useful.

They are just solving a narrower problem.

They decide what runs. They do not decide what should be required for merge.

If your team is fighting GitHub required-check rigidity, the missing piece is usually conditional merge policy, not more workflow tricks.

We built MergeGuard around exactly that gap: one deterministic status for context-aware checks, approvals, and merge readiness.

Top comments (0)