gitlab-workflow

Install code-review-core alongside this. On its own there is nothing for this plugin to post. The core runs the review and writes .code-review/VALIDATED.json; this plugin talks to GitLab. They communicate through that one file and nothing else.

It is deliberately the same shape as github-workflow, because two transports over one core that disagree about structure are harder to maintain than either alone. One thing genuinely differs. A GitLab inline comment needs a position object — base_sha, head_sha, start_sha, new_path, old_path, new_line — where GitHub needs a path and a line, and those three SHAs come from the merge request's own diff_refs. Get that wrong and the summary note still posts while every inline comment fails, which reads as a working transport that happened to find nothing inline. The script fetches diff_refs once and refuses without them.

Beyond the transport it owns the merge request lifecycle over glab and .gitlab-ci.yml authoring: rules: rather than the legacy only/except, needs: for a DAG, the cache-versus-artifacts distinction, OIDC id_tokens instead of stored cloud keys, and pinning every remote include: to a tag or a SHA rather than a branch.

Prerequisites are glab, authenticated, and jq. Both must be present; the posting script exits non-zero rather than degrading, because a transport that half-works posts half a review.