Documentation

Configure prmerger around the Java workflow your team already trusts.

prmerger reviews Java pull requests, runs Maven or Gradle build checks, verifies unit tests stay green, and flags bug risk before code reaches main.

Best fit

  • GitHub repositories where Java pull requests must respect an existing build truth.
  • Teams using Maven or Gradle who want unit test failures to block merges automatically.
  • Engineering groups that want AI review comments focused on defect risk, not generic style feedback.
Setup

Rollout happens in three pieces.

Choose the pull request command

Pick the Maven or Gradle command that must pass before a Java PR can merge. This can be a full build or a module-scoped test entrypoint.

Connect your repository policy

Define which branches are protected and whether prmerger should block on build failures, unit test failures, or both.

Start reviewing live pull requests

prmerger runs the configured command, inspects the diff, posts review findings, and keeps the verdict tied to the latest commit on the PR.

Commands

Use the exact Java command that should decide merge readiness.

Gradle

./gradlew test

Use your existing Gradle wrapper command when the whole Java application or module test suite should be authoritative.

Maven

mvn -B verify

Use Maven verify when your team wants compile, test, and packaging state represented in the PR verdict.

Monorepo module

./gradlew :checkout-service:test

Scope the command when the repository contains several services and you want the review to align with the impacted Java area.

Merge Policy

What keeps a pull request blocked.

  • Build red means merge blocked. prmerger never marks a pull request clean when the configured Maven or Gradle command fails.
  • Unit test failures stay visible on the PR. Authors see the failing test names and stack traces directly in context.
  • Critical review findings keep the verdict open until the code changes or the reviewer explicitly resolves the issue.
  • Every new commit on the PR reruns the review so the verdict always reflects the latest branch state.
Review Focus

The AI review concentrates on Java changes that can actually create bugs.

Null safety and error-handling changes in services

Controller and DTO changes that can break contracts

Repository logic that can hide query or transaction issues

Test suite regressions that weaken edge-case coverage

FAQ

Common rollout questions from Java teams.

Do we have to adopt a new build pipeline?

No. prmerger is designed to respect the build command and branch protection flow you already run today.

Can reviewers override a failing result?

Teams can define their own policy, but the default model is conservative: broken build or broken tests means the PR is not ready to merge.

Does it comment on every file?

No. It concentrates on bug risk in changed Java code and related tests instead of spraying style commentary across the diff.