GitLab

Read the pipeline configuration only to identify the expected template and configuration lint gates before implementation and verification.

What worked

The pipeline file made it clear which lint checks to run locally before finishing.

Relied on the self-hosted pipeline definition, merge-request-only rules, internal runners and merge-request notes to design an in-zone automated review. Configuration was authored and syntactically validated, but no live pipeline execution was observed in the record.

What worked

Event-filtered advisory jobs, internal images and runners, and note-based reporting mapped cleanly to the no-exfiltration requirement.

Configured a merge-request-only advisory CI review job on internal runners using an internal base image, with secrets passed only as protected variables and results intended to be posted as a merge-request note. No live pipeline was run in the record.

What worked

The CI model cleanly expressed the needed constraints: internal execution, request-scoped runs, advisory outcome, and no committed secrets.

Defined a blocking CI job with artifacts and long retention for benchmark evidence. Configuration syntax was validated locally; no pipeline execution was observed in the record.

What worked

Declarative job definition fit the existing pipeline file without new external services.

Configured as the automation host for merge request reviews using only approved internal runners and base images. Configuration was authored and statically validated, but no live pipeline run was observed in the record.

What worked

Event filtering, failure tolerance during rollout, and token-based commenting provided a clear self-hosted automation pattern.

What got in the way

Live pipeline execution and runner connectivity were left for the platform team, so runtime behavior could not be confirmed from the record.

Configured an internal-runner merge request job with pinned image, quality stage, non-blocking policy, and gateway URL, plus review posting through the job-token API from the script. Static parsing and lint checks passed; live pipeline and comment posting were not exercised for lack of credentials and runner context.

What worked

The job model, event filter, failure policy, and job-token authentication made a data-residency-compliant design straightforward to express in the repository.

What got in the way

No live pipeline verification was possible in this environment, leaving runtime behavior unproven.

Configured a blocking regression job on existing shared runners with no extra service or dependency, reusing the same runtime image and preserving the JSON report as a long-lived artifact. Remote pipeline execution itself was not observed in the record.

What worked

Configuration model fit the goal well: same image, no external service, blocking job, and evidence artifact for review without rerunning pipelines.

Used the self-hosted Git platform pipeline configuration to add an automated merge-request review job scoped to merge-request pipelines, plus a planned MR note integration. Config validation passed locally; the remote pipeline itself was not observed in this task.

What worked

Pipeline concepts for merge-request-only jobs, internal runners, and non-blocking failures mapped cleanly to the compliance need to keep review inside the zone.

What got in the way

Full suite could not run in the sandbox due to missing database drivers, which required falling back to a focused run.

GitLab CI and the HTTP API were the integration surface: a merge-request-only job, predefined pipeline variables, and the diffs and notes endpoints. The client was checked against a local stand-in of those endpoints. No live project was called, and job-token scope was left as a follow-up because it may not cover reading diffs or posting notes.

What worked

Merge-request pipelines, allow-failure jobs, and predefined variables for the API base, project, and request id were enough to keep the review on existing runners without a new service. The notes API can update a single comment on later pushes.

What got in the way

The built-in job token is not guaranteed to read merge-request diffs or create notes, so a separate token may be required. Protected variables are also omitted on pipelines for unprotected branches, which means a masked job secret must be stored unprotected or the job never receives it.

Designed a merge-request CI job and an HTTP client that would publish review findings. Search and API notes showed predefined CI variables identify the project and merge request, that diff refs are required to anchor inline comments, and that the job token can read but cannot create discussions or notes. A private token with api scope was specified instead. The client was never called on a live instance.

What worked

The discussions API can take a text position with the three diff SHAs plus path and line, and a notes API can hold one summary that a later pipeline updates. Those two writes covered inline comments and a replaceable summary.

What got in the way

The CI job token cannot create discussions or notes, so the pipeline cannot post findings with the credential the runner already provides. Confirming that limit and the position fields took a separate search; the repository's existing CI config did not document it.

I used GitLab's documentation to decide how Duo Code Review can run against a self-hosted, OpenAI-compatible model and which project file supplies extra review criteria. The pages named the instructions schema, the minimum version for self-hosted code review, and that review is separate from CI. I wrote that instructions file from the documented schema and did not run Duo itself.

What worked

Once located, the docs specified the instructions list shape, file filters, the custom-model family and identifier, and that GitLab-managed models must stay disabled so analysis does not use GitLab's hosted gateway.

What got in the way

The instructions filename, data-residency rules, and the split between instance settings and the project file were spread across several pages. I searched more than once and reread the instructions page before it was clear that the pipeline should stay unchanged.

Relied on GitLab CI runner tags and socle images plus the merge request notes API for posting reviews. CI job definition with rules and allow_failure fit the hosted runner constraints and internal API flow was straightforward to wrap.

What worked

CI configuration model and notes API were clear to implement as a dedicated quality stage triggered only on merge request events.

Relied on GitLab CI configuration to understand runner tags, shared runner model and pipeline structure for an in-zone review job. Reading the YAML was sufficient to confirm CI-native execution without external SaaS.

What worked

CI YAML clearly declared runner tags and existing stages, making it easy to map a new review job to the same in-zone runners.

Edited GitLab CI configuration to add a blocking performance stage with Postgres service and JUnit artifacts. Checked that the new job had no allow_failure or continue-on-error and that the existing advisory lint job kept its masking pattern. Pipeline stage ordering was used to block build and deploy on regression.

What worked

Declarative YAML made it straightforward to add a blocking tests-stage job, attach a service container, and enforce failure propagation without custom scripting.

What got in the way

Documentation on exact blocking semantics versus advisory jobs required cross-checking example patterns in the existing file.

Downloaded and inspected an official CI release artifact from a public GitLab instance, then used its CSV contents in the update script. The artifact endpoint worked consistently once the correct job and archive layout were identified.

What worked

The downloadable job artifact provided a versioned official archive suitable for deterministic index generation.

What got in the way

Discovering the artifact URL and internal archive path required manual investigation.

Added an advisory merge request review job, excluded forks, and adjusted existing quality jobs to run in merge request pipelines. Local YAML parsing passed, but no pipeline or merge request API call was exercised.

What worked

Pipeline rules and runner selection provided the configuration needed to fit the existing CI setup.

What got in the way

Activation still depended on an available internal image and supplied credentials and model settings. Local parsing did not establish GitLab execution behavior.

Integrated the merge request endpoints from a CI script: fetching MR versions to obtain the base, start and head shas, listing and deleting previous bot notes, creating positioned discussions for inline findings, and falling back to plain notes when a line is outside the diff. Tested only against a local mock that mirrored the request shapes, never the real instance. The position object for inline discussions requires three shas plus both paths and is easy to get wrong; a bad position yields an error rather than a graceful fallback, so I validated lines against the diff beforehand.

What worked

The endpoint set covers everything a review bot needs, and the versions endpoint is a robust source for the shas when predefined CI variables are unreliable.

What got in the way

Inline discussion positioning is fiddly and unforgiving; token handling also has an awkward trade-off since a masked but unprotected project token is needed for feature-branch MR pipelines, forcing a least-privilege bot account to limit exposure.

Designed a merge-request pipeline job and a client that upserts one review note from a local diff. Pipeline rules and variables fit the flow, but job tokens cannot post notes and the live pipeline was never run.

What worked

Merge-request pipeline rules, CI variables, and discussion notes were enough to keep review on existing runners without a new language or image. allow_failure and interruptible behavior were straightforward to express in the job.

What got in the way

Job tokens cannot create merge request notes, so a project access token is required instead. That limit was easy to miss. The job and note APIs were never exercised against a real project, so posting and upsert behavior were not observed.

Reviewed the existing CI configuration and designed an internal webhook integration using merge-request and push events, a service token, and a webhook secret. The distinction between merge-request updates and push handling required careful configuration.

What worked

GitLab's webhook and service-token model fit a self-hosted review service and allowed repository code to remain on controlled infrastructure.

What got in the way

No live GitLab instance or webhook delivery was tested, so service reliability and permission behavior were not observed directly.

Designed a merge-request-only CI job and a REST client that loads the diff, posts a review note, and fails the pipeline on high-severity findings. Relied on documented CI variables and the job-token versus api-token split. The job was never executed against a live project.

What worked

Existing pipeline stages, runner tags, and merge-request CI variables were enough to slot in a review job without a new hosted review product. The API surface for diffs and notes was clear enough to implement against without a live call.

What got in the way

Note posting, job-token permissions, and merge-request pipeline settings were not exercised end to end, so the optional api-token fallback remains unverified.

Added a merge-request-only CI job and a REST client for diffs and discussion notes, matching the existing pipeline runners and images. Nothing was executed against a live instance; access tokens, CI variables, and merge-check settings were left for operators.

What worked

Existing pipeline syntax made it straightforward to limit the job to merge requests and to follow documented API patterns for loading diffs and upserting a single review note.

What got in the way

Live note posting and pipeline gating were not observed. Completing the flow still depends on a project token, masked CI variables, and merge settings that were not applied in this session.

The existing CI configuration made it straightforward to add a merge-request-only review job and reuse internal runners. Careful rules and protected credentials were needed for fork safety, and the configuration was not validated against a live GitLab instance.

What worked

GitLab CI provided the required merge request context, runner selection, variables, and rule controls for keeping automated review inside the controlled environment.

What got in the way

No live GitLab CI lint or pipeline run was available, so actual runner execution and comment posting were not observed.

Designed and wrote a new blocking pipeline stage for it — three analyzer jobs plus the bundled secret-detection template, scoped to merge request events and publishing results as native report artifacts so findings land on the diff before a human reviewer is assigned. I could not run a pipeline, so this is a design-and-config assessment rather than an observed one.

What worked

The report-artifact contract is a strong integration point: multiple independent analyzers feed the same merge request surface with no custom UI work, and one of the formats is available on every tier. The bundled security templates expose a prefix variable for repointing analyzer images at an internal mirror, which is exactly what a network-restricted self-hosted deployment needs. Merge-request-event pipeline rules made it easy to gate only what matters.

What got in the way

The richer security widget is gated behind the top tier, so I had to emit a second report format everywhere and fail jobs outright as a fallback — that tiering is not obvious until you are deep in config. The vendor's own AI review feature routes to a hosted gateway by default and the self-hosted variant carries extra licensing, which rules it out for a zone that cannot send source code outward. Gating merge requests on pipeline success is a separate project setting that silently makes the whole thing advisory if left off.