DEV Community: Marcus Vinicius Tavares

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

Marcus Vinicius Tavares — Sun, 29 Mar 2026 23:38:39 +0000

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:

Should this workflow run?
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/**"

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.

AI Can Speed Up Code Review — but Merge Decisions Still Need Deterministic Guardrails

Marcus Vinicius Tavares — Sun, 22 Mar 2026 22:03:17 +0000

AI Can Speed Up Code Review — but Merge Decisions Still Need Deterministic Guardrails

AI is already useful in pull request workflows.

It can:

summarize diffs
explain code changes
suggest fixes
identify risky files
draft reviewer context
reduce reviewer fatigue

That is real value.

But there is a line teams should be careful not to cross:

AI can accelerate review. It should not be the final authority on merge.

TL;DR

Use AI to help people review code faster.

Do not let a probabilistic system be the thing that ultimately decides whether a pull request is allowed to merge.

That final decision should come from deterministic policy.

Why this matters

Code review and merge governance are related, but they are not the same problem.

Review is exploratory.

Merge is enforcement.

At merge time, the system is no longer asking, “What might be risky here?” It is asking:

Did the right people approve?
Did the required checks pass?
Does this change affect sensitive paths?
Does it meet branch-specific rules?
Are exception paths allowed for this case?
Is it safe to merge right now?

Those answers need to be:

consistent
auditable
predictable

That is what deterministic means in practice.

For the same inputs, the system should produce the same merge decision every time.

Where GitHub helps — and where it stops

GitHub gives teams solid primitives:

protected branches
required reviews
CODEOWNERS
status checks
auto-merge
merge queue

Those features matter. They are the starting point for safe repositories.

But real governance gets more contextual as teams grow.

A docs-only change should not necessarily be treated the same way as a change under billing/.

A small refactor in one area of the system should not necessarily be governed the same way as a pull request that changes:

application code
infra/
authentication config

That is where static configuration starts to break down.

The “single approval” trap

A common example is CODEOWNERS.

Teams often assume that if multiple teams own a path, then all relevant stakeholders will need to approve changes touching that area.

In practice, many setups end up enforcing something much weaker: one approval from one matching owner is enough.

That can create a dangerous false sense of safety.

A pull request can look fully approved in the UI even when only part of the actual review requirement was satisfied.

That usually leads to a pile of compensating controls:

custom GitHub Actions
reviewer-combination scripts
Slack-based exception handling
manual release-manager checks
tribal knowledge about what “really” needs approval

That is not a policy system. That is policy scattered across tools and habits.

What teams actually need

Teams do not just need more repository settings.

They need a merge policy layer.

That policy layer should be able to express rules like:

Changes under infra/ require platform approval
Changes under billing/ require billing-owner approval
Multi-domain changes require approval from each affected domain
Docs-only changes can merge with lighter requirements
Emergency hotfixes can take a controlled exception path
A pull request merges only when the exact review and check requirements for that change type are satisfied

Those are normal requirements in real engineering organizations.

They should be encoded and enforced, not left to luck.

Governance as code is the scalable answer

The scalable model is governance as code.

Instead of spreading review logic across repository settings, scripts, and memory, define it from a structured source of truth.

That source of truth can describe:

ownership
systems and domains
required reviewers
sensitivity levels
exception paths
environment-specific rules

From there, merge enforcement becomes much more reliable.

You can keep ownership definitions centralized, keep CODEOWNERS aligned automatically, validate exact approval requirements, and explain why a pull request was allowed or blocked.

That is a much better fit for modern teams than static repository rules alone.

Where AI fits

AI fits well in the assistive layer.

Use it to:

summarize pull requests
identify likely reviewers
suggest missing tests
explain unfamiliar code
highlight unusual changes

That is where probabilistic systems are strong.

But merge is different.

If an AI says, “this looks safe,” that may be useful input.

It is not enforcement.

Nobody would replace CI with “the model thinks the build is probably okay.”

Merge governance deserves the same discipline.

A better operating model

The right model is not human-only review.

It is also not AI-only control.

It is a layered system:

humans provide judgment
AI provides acceleration
deterministic policy provides enforcement

That gives teams speed without giving up trust.

Where MergeGuard fits

This is exactly the gap MergeGuard is built to close.

MergeGuard adds a deterministic policy layer to GitHub pull request workflows, so teams can enforce the review and approval logic they actually need.

That means policy can reflect reality:

which parts of the system changed
who owns them
which approval combinations are required
which exceptions are allowed
when a pull request is truly safe to merge

The goal is not to replace GitHub’s controls.

It is to extend them into something more context-aware and more trustworthy.

That matters even more if your team is experimenting with AI-generated code, agent-created pull requests, or more aggressive automerge paths.

The faster code moves, the more important deterministic enforcement becomes.

Closing

AI should absolutely make pull request workflows faster.

But merge is not just another productivity step.

It is a governance decision.

And governance works best when it is deterministic.

AI should suggest and accelerate. Deterministic policy should decide and enforce.

If your team wants deterministic merge policy for GitHub pull request workflows, learn more at mergeguard.dev.