## Summary When Duo Code Review is enabled at the group or project level, it applies uniformly to all merge requests. There is currently no way to define which merge requests should — or should not — be eligible for automatic review. The only available control is an all-or-nothing toggle per project or group. ## Problem in detail Teams adopting Duo Code Review at scale consistently encounter situations where they want the feature enabled broadly, but need to exclude or limit it based on the characteristics of individual merge requests. Today that's not possible. The feature either runs for everything, or it must be disabled for an entire project or group. This creates a real adoption barrier. Enabling Duo Code Review at the group level means accepting it indiscriminately across every MR in every project — regardless of whether the MR is the kind of work the team actually wants reviewed. Teams are being asked to make a binary choice between "review nothing" and "review everything," when what they need is meaningful control in between. Two specific patterns surface this gap clearly: **Bot-authored merge requests.** Automated tooling like Renovate routinely creates large volumes of MRs for routine dependency updates. These are not the kind of changes teams want AI code review applied to — the signal-to-noise cost is high, the value is low, and it can consume compute or review credits unnecessarily. Teams need a way to enable Duo Code Review for human-authored work without it also running on every bot-created MR. **Target branch scope.** Many organizations have change-control and compliance policies that are anchored to branch protection. They want AI-assisted review to participate only where those policies already apply — on changes headed to protected branches — not on every feature branch or experimental change across the repo. There is currently no way to align Duo Code Review's scope with existing branch-protection semantics. Both of these are the same underlying gap: the feature has no understanding of MR eligibility. It treats every MR as equivalent at the moment it's triggered, with no mechanism for teams to express that some MRs should be in scope and others shouldn't. ## Who this affects Teams and organizations that want to adopt Duo Code Review at scale but have heterogeneous MR workflows — including bot automation, multi-branch strategies, or compliance requirements that don't map cleanly onto a project-level on/off setting. ## Why this matters Without eligibility controls, the cost of enabling Duo Code Review broadly is accepting unwanted automation on low-value or policy-inappropriate MRs. That friction is causing customers to hold off on group-level enablement entirely, which limits adoption of the feature in exactly the environments — large, complex organizations — where it has the most potential value. ## Proposal ### Configuration file Introduce a new optional configuration file at: ``` .gitlab/duo/mr-review-automated-rules.yml ``` This follows the existing convention established by `mr-review-instructions.yml` and leaves the file open to accommodate additional automation-related controls in the future. When present in a project, the file is read before any automatic Duo Code Review is triggered. If the MR matches any condition in the `exclude` block, the automatic review is skipped. Manual reviews — triggered by commenting on an MR — are not affected. ### Matching behaviour Conditions within `exclude` are evaluated with OR logic: if a MR matches **any** condition across any field, it is excluded. This keeps the configuration simple and predictable, and matches the most common real-world need. ### Pattern matching All values support glob syntax (`*` matches any sequence of characters, `?` matches a single character). Matching is case-insensitive. For author matching, values should correspond to the GitLab username of the MR author. ### Supported fields (v1) | Field | Description | |---|---| | `exclude.authors` | Skip review when the MR author's username matches | | `exclude.source_branches` | Skip review when the MR source branch matches | | `exclude.target_branches` | Skip review when the MR target branch matches | Draft MR status is already handled separately — automatic review is withheld until a draft is marked ready. Label and title-based filtering are out of scope for this iteration. ### Inheritance The file can be defined at both the **project level** (in the project repository itself) and at the **group level** (in a designated group configuration project). Rules from both levels are merged and evaluated together — a MR is excluded if it matches any rule at either level. This allows platform or security teams to define org-wide exclusions (e.g. all bot authors) at the group level, while individual projects can layer on their own rules without duplicating the group-level ones. ### Schema ```yaml # .gitlab/duo/mr-review-automated-rules.yml # # Controls which merge requests are eligible for automatic Duo Code Review. # When a MR matches ANY condition in the exclude block, automatic review is skipped. # Manual review (triggered via a comment) is unaffected by these rules. # # Pattern matching uses glob syntax (* matches any sequence of characters, # ? matches a single character). All matching is case-insensitive. # Authors should match the GitLab username exactly, with globs where needed. version: 1 exclude: # Skip automatic review for MRs opened by these authors. # Useful for filtering out bot-generated dependency update MRs. authors: - renovate-bot - dependabot - "*-bot" - "bot-*" # Skip automatic review for MRs whose source branch matches these patterns. # Useful when bots or automation use predictable branch naming conventions. source_branches: - "renovate/*" - "dependabot/*" - "auto-update/*" # Skip automatic review for MRs targeting these branches. # Useful for excluding feature, spike, or experimental branches. target_branches: - "feature/*" - "spike/*" - "wip/*" ```