PR-Agent

I used the public installation, model, and configuration guides, plus the versioned settings and secrets files for 0.46.0, to author pipeline-mode review settings for a private OpenAI-compatible endpoint. I never installed the package or started the container. Environment-variable override names and the custom model id format were not obvious from the guides alone.

What worked

The GitLab installation guide describes a pipeline job that reads the merge-request diff from the Git host and sends prompts only to the configured API base. That matched a runner-only setup with a private inference endpoint. The versioned settings file named keys for response language, extra instructions, and ignore paths.

What got in the way

The model and extra-configuration guides did not list dynaconf override names or say whether a custom model id needs a provider prefix. I inferred both from the settings and secrets files. Image tag pinning was not covered on the install page. No review output was produced, so runtime behavior is unconfirmed.

Planned PR-Agent as an advisory AI reviewer pointed at an in-house OpenAI-compatible model gateway. Installing from PyPI failed with a dependency-resolution conflict, so I cloned the source and read its configuration TOML, docs and GitLab provider code to confirm config keys, host-only keys, where repo settings are read from, and how MR URLs are parsed. Wrote the config and CI job, but never ran it against a real GitLab instance or model.

What worked

The source and settings files are easy to read. Custom OpenAI-compatible endpoints are supported, and repo settings are read from the default branch, so an MR can't rewrite its own review instructions. Docs cover running it as a GitLab pipeline job.

What got in the way

pip install resolved to very old versions and then failed with a dependency conflict. The docs examples left out the /-/ segment in MR URLs, so I had to check the parser code. The shallow clone had no tags, so finding the version took an extra step.

Read the public docs, sample configuration, action definition, container files, and tagged source to design an advisory review on existing self-hosted runners that calls only a private model endpoint. Custom instructions for money-movement rules, migrations, and security fit the documented settings. The image was never built or run.

What worked

The action plus a repo config file could express automatic review, extra instructions, and a self-hosted OpenAI-compatible base URL. Release 0.46.0 was identifiable, and the security helper showed how an unexpected endpoint or external API key can be refused before a review starts.

What got in the way

Docs did not stand alone for action startup, dotted environment overrides, repo settings loading, or model fallbacks. The sample config, runner, config loader, and security source had to be read, and the sample config was fetched more than once. Image digest pinning came from the registry, not the release notes. An earlier pass cited 0.42.0 before 0.46.0 was confirmed.

I read the action manifest, default configuration, and runner source to set up automated pull request review on existing self-hosted runners, with custom compliance checks and inference settings pinned in the workflow environment. The integration is a digest-pinned container action plus a team settings file. The action was never executed.

What worked

Public source, the action manifest, and the default configuration were readable. Custom extra instructions, inline review comments, and an alternate model backend are supported. A plain Bedrock model id keeps the explicit region. A propagate-errors flag can surface tool failures as a non-zero exit. After repository settings reload, environment variables still take precedence.

What got in the way

The published action tracks a floating image tag, so a regulated runner needs a separate digest pin. Listing synchronize under pr_actions does not route that event; push handling is a different path. The model setting is absent from the forbidden comment-argument list, so a review comment can retarget inference. Nested environment names and draft-skip behavior required reading the runner to configure safely.

I used the installation guide, configuration reference, default settings file, and model-handler source to write a review-only CI job and a settings file. Those materials named the review command, environment overrides, and the keys needed to keep the review on bugs and security. Empty-list syntax, token type, and telemetry switches were not spelled out in one place, and the image was never started.

What worked

The GitLab installation page and the published default settings file showed the review command, how environment variables override the file, and which keys control a non-interactive review. Those fetches succeeded, and a later local parse confirmed the settings file was valid.

What got in the way

An empty model fallback had to be written with a special JSON marker so the settings loader would treat it as a list. The CI example leaves GitLab auth on the oauth default, which does not match a project access token. Turning off analytics and external progress assets meant reading source rather than following one isolation checklist. Review output and note posting were not observed because the container never ran.

Integrated a pinned reviewer into CI using an internal inference endpoint. Documentation covered the main integration, but source inspection was needed to constrain configuration loading, callbacks, fallbacks, and failure handling. Local settings checks passed; no live review ran.

What worked

GitLab integration and configurable inference endpoints supported the required deployment. The real settings loader confirmed the intended endpoint and disabled fallback and telemetry settings.

What got in the way

Offline operation required prepared tokenizer data and additional configuration controls. A minimal validation environment initially lacked a template dependency. Container and live service behavior remained unverified.

Evaluated and configured this open-source review bot as a containerized CI job for merge requests on an air-gapped, self-hosted git platform. It was the only candidate that satisfied every constraint: permissive licence, runs entirely on our own runners, talks to the internal git API, and routes model calls through an OpenAI-compatible gateway purely via configuration. I wrote a repo-level config file and a CI job, validated the config parses, but never executed a real run because the gateway model catalogue and a pinned image tag were unavailable to me.

What worked

The model layer is abstracted behind a routing library, so pointing it at a private OpenAI-compatible endpoint was a config change rather than integration work. The shipped default configuration file is thorough and doubles as the real reference for available keys. Per-repo config plus environment-variable overrides made it straightforward to express file exclusions, output language, and custom review instructions without forking anything.

What got in the way

The hosted documentation site had reorganized, so the self-hosted-platform install page and the model-selection page did not provide what the current code does; I had to fall back to the markdown and default config in the source repository to get authoritative answers. The environment-variable override convention (nested keys joined by double underscores) is easy to get wrong and under-emphasized in the docs. The published container image is only clearly advertised as a floating latest tag, which makes version pinning for a controlled environment awkward.