GitLab: reviewers config doesn't stop Automatic reviewer assignment (CODEOWNERS) because createPr() sets reviewer_ids after MR creation, not during

[shubhamdhingra007]

What are you trying to do?

On GitLab, we enabled Automatic reviewer assignment (reviewer_assignment_strategy: code_owners) so that CODEOWNERS get auto-added as reviewers on human PRs, but not on Renovate's dependency-update MRs — the docs say GitLab skips the auto-assignment when "the merge request already has a reviewer", so we set Renovate's reviewers config expecting that to satisfy the skip condition.

It doesn't. Every Renovate MR still gets the full CODEOWNERS reviewer list added on top of our configured reviewers.

Current behavior

Every Renovate-created MR on a project with a CODEOWNERS file and reviewer_assignment_strategy: code_owners ends up with all CODEOWNERS-matched reviewers plus whatever is in reviewers/reviewersFromCodeOwners — even though reviewers is set.

Root cause we traced

createPr() creates the MR via POST /merge_requests without reviewer_ids:

const res = await gitlabApi.postJson<GitLabMergeRequest>(
  `projects/${config.repository}/merge_requests`,
  {
    body: {
      source_branch: sourceBranch,
      target_branch: targetBranch,
      remove_source_branch: true,
      title,
      description,
      labels: (labels ?? []).join(','),
      squash: config.squash,
    },
  },
);

Reviewers are only added afterward, in a separate call from addReviewers(), invoked later via addParticipants in lib/workers/repository/update/pr/index.ts:

mr = await getMR(config.repository, iid); // fetch CURRENT reviewers
// ...
await updateMR(config.repository, iid, {
  reviewer_ids: [...existingReviewerIDs, ...newReviewerIDs], // preserves whatever is already there
});

Because the MR is created in ready (non-draft) state with zero reviewers, GitLab's own Automatic reviewer assignment sees "MR created in ready state" + "no reviewer yet" and immediately assigns every CODEOWNERS match — before Renovate's separate addReviewers() call ever runs. By the time that call executes, it fetches the already-populated reviewer list and just appends our configured reviewers on top. The MR is never in a state where it "already has a reviewer" at the moment GitLab's skip-check runs.

Confirmed this isn't specific to Renovate's reviewer handling: we checked two MRs authored directly by a human (no Renovate involvement, no reviewer config at all) on the same project — the exact same CODEOWNERS reviewer list gets added within ~2 seconds of MR creation, via a system note attributed to the MR author. This rules out anything about how Renovate resolves reviewers/reviewersFromCodeOwners; it's purely about when a reviewer exists relative to MR creation.

Expected behavior

If reviewers (or reviewersFromCodeOwners) is configured, Renovate should include the resolved reviewer_ids inline in the POST /merge_requests call that creates the MR, so the MR is never created with zero reviewers, and GitLab's documented skip condition can actually apply.

Reproduction

A throwaway public-repo reproduction isn't practical here, because Automatic reviewer assignment is a GitLab Premium/Ultimate-tier project setting, which a free public GitLab.com repo can't enable. To reproduce on a Premium/Ultimate namespace:

1. Add a CODEOWNERS file matching all files, e.g. * @some-group.
2. Settings → Merge requests → Automatic reviewer assignment → "Automatically assign all code owners as reviewers".
3. Configure Renovate with "reviewers": ["some-other-user"].
4. Run Renovate and let it open an MR — the resulting MR's reviewers include the CODEOWNERS group members and some-other-user.

Happy to share sanitized evidence from our real-world case (GitLab API responses for merge_requests/:iid, /approval_state, project reviewer_assignment_strategy, and system-note timestamps) if that helps confirm the timeline — omitted here for confidentiality.

Suggested fix

Resolve reviewer usernames/group members to IDs (the logic already exists in addReviewers/expandGroupMembers) before calling platform.createPr() on GitLab, and pass reviewer_ids in the initial POST /merge_requests body instead of doing it as a separate post-creation call.

Happy to put together a PR if maintainers are open to this — would appreciate guidance on the preferred shape, since it touches the shared createPr/addParticipants ordering in lib/workers/repository/update/pr/index.ts, not just the GitLab-specific file.

---

Disclosure: this report was investigated with AI assistance (root-cause tracing and code search), reviewed and verified against live GitLab API responses by a human before posting.