Quick Start
Set up PatchPatrol in GitLab CI and learn how to inspect the generated review reports.
Introduction
PatchPatrol runs AI review as a supported public path: GitLab artifact-first CI. Start with the pinned GitLab component include when it is available on your GitLab instance, then read the generated artifacts before enabling optional delivery modes. Use the direct job fallback from the install guide when the component has not been published for your instance yet.
PatchPatrol is a product by aistack. Visit the PatchPatrol website or contact PatchPatrol for product context.
PatchPatrol has four starting points:
Workspace admin
Prepare registry access, CI variables, and the supported GitLab review job.
Developer user
Run the merge request path and read the artifacts once access is ready.
First output
Open `ai-review.html` or `ai-review.md` first, then use `ai-review.json` when structured detail matters.
Troubleshooting
Recover when setup, artifacts, provider trust gates, or delivery do not match the baseline.
Want to learn more?
New to PatchPatrol? Read What is PatchPatrol?, then return here for the artifact-first rollout steps.
Docker Authentication
Registry access: because GitLab pulls the job image before
scriptruns, configureDOCKER_AUTH_CONFIGas a masked GitLab CI/CD variable, not inside.gitlab-ci.yml.
Create the variable value locally from your registry username and password:
AUTH="$(printf '%s:%s' "$PATCHPATROL_REGISTRY_USERNAME" "$PATCHPATROL_REGISTRY_PASSWORD" | base64 | tr -d '\n')"
printf '{"auths":{"registry.patchpatrol.ai":{"auth":"%s"}}}\n' "$AUTH"Add the printed JSON as the value of a masked DOCKER_AUTH_CONFIG variable in
GitLab project or runner settings. The component job can then pull
registry.patchpatrol.ai/patchpatrol:latest before its script starts.
Pipeline Config
# .gitlab-ci.yml (excerpt)
include:
- component: $CI_SERVER_FQDN/patchpatrol/components/gitlab-review@1.0.0
inputs:
feedback-mode: artifact-only
readiness-mode: 'off'
output-dir: .ai-review
artifact-expire-in: 7 daysReview MR comments
Start with the artifact output created by the component job. Open
.ai-review/ai-review.html or .ai-review/ai-review.md for the human-readable
review and .ai-review/ai-review.json for structured detail. If you later
enable merge request comments, use Feedback modes
after the artifact-first baseline is working.
# quick provider/config validation before the first artifact-only run
ai-review test --chat --readiness-jsonReal-provider chat probes require a valid Self-Hosted License through
PATCHPATROL_LICENSE or PATCHPATROL_LICENSE_FILE; license failures stop
before provider calls with exit code 12. Dry-runs, mock-provider checks, and
non-chat readiness checks remain available without a license.
Pin the component include to the SemVer release published for your GitLab instance; do not use
@latestfor component references. Leave componentreadiness-modeoff for artifact-only rollout; turn on GitLab readiness only with MR feedback and the required token/context. KeepAI_REVIEW_FEEDBACK_MODEset toartifact-onlyfor your first rollout. Supported public path: GitLab artifact-first
Continue setup
Operator map
Use these paths when the first artifact-first run is moving from setup into team usage.
For role handoff and optional delivery after the first artifact-first run, use Access and roles and Feedback modes.
If the first run fails, artifacts are missing, or GitLab delivery does not match the expected artifact-first baseline, go straight to Troubleshooting before widening the rollout.
Reference paths
Before rollout
Support contract