LogoLogo
HomeAbout usSign up
  • Introduction
  • AttentionSet
    • AttentionSet Best Practices
    • How to View AttentionSet for Others
    • How to Manually Change Attention
    • AttentionSet Chrome extension
    • Attention reasons
    • AttentionSet Slack Home Page
  • Releases
    • Getting Started with Releases
    • Concepts for Releases
      • Terminology for Releases
      • Two-step delivery
      • Rollbacks
      • Cherry-picks
      • Dogfood, Canary and Rollout
      • Release notes
    • How-to Guides for Releases
      • How to Create a Release Project
      • How to Configure Environments
      • How to Create a Scheduled Release
      • Create Custom Workflow Parameters
      • How to Manage Cherry-Picks
      • How to Resolve a Cherry-Pick Failure
      • Working with your CI / CD
        • GitHub Actions workflow
        • Buildkite workflow
    • API Reference for Releases
  • FlexReview
    • Getting Started with FlexReview
    • How to Onboard a Large Org
    • Concepts for FlexReview
      • Read-Only Mode in FlexReview
      • Recursive Ownership in FlexReview
      • Reviewer suggestion and assignment
      • FlexReview Teams and SLO Management
      • Validation in FlexReview
    • How-to Guides for FlexReview
      • How to Get a Reviewer Suggestion
      • How to Exclude Reviewers
      • How to Set Up Team Rules
      • Whitelist Teams for Review Assignment
      • Troubleshoot Reviewer Assignment
      • PagerDuty Integration for Reviewers
      • How to Set Up FlexReview Validation
      • Recommended Slack Notification Settings
      • How to Exclude OOO Reviewers
    • FlexReview Reference
      • Configuration
      • Slash commands
      • Expert scoring algorithms
      • Slack Notifications
      • Out of Office User Exclusion
    • FlexReview Roadmap
  • MergeQueue
    • Getting Started with MergeQueue
    • Merge Rules
    • How-to Guides for MergeQueue
      • How to Configure Base Branches
      • How to Customize Required Checks
      • How to Set Up Fast-Forwarding
      • How to Set Up Pre-Queue Conditions
      • How to Queue / Dequeue via API
      • Pause / Unpause Queues via API
      • Slash Commands Using GitHub Comments
      • How to Customize Sticky Comments
      • Require an Aviator Status Check
      • Backport a PR
      • How to Configure ChangeSets
      • Custom Integrations
        • GitHub Integration
      • How to Create Personal Access Tokens
      • How to Set Up SAML Configuration
        • Microsoft Active Directory
      • How to Merge Stacked PRs
      • How to Block Pull Request Mergeing with Slash Commands
    • Concepts for MergeQueue
      • Queue Modes
      • Pull Request Lifecycle
      • Analytics
      • Parallel Mode
      • CI Status Requirements
      • MQ Created Branches
      • Batching
      • Managing flaky tests
      • Fast-forwarding
      • Pre-Queue Conditions
      • Sticky Comments
      • Backporting
      • Paused Queues
      • Affected Targets
        • Directory-Based Affected Targets
        • nx based affected targets
        • GitHub Actions based Affected Targets
      • ChangeSets
        • Global CI Validation
        • ChangeSets FAQs
      • Priority Merges
        • Instant Merges
      • Merge Rules Audit Trail
      • Timeline
      • Ready Hook
      • Reduce Queue Failures From Staleness
    • MergeQueue References
      • Configuration Schema
      • Configuration Reference MergeQueue
      • GitHub Slash Commands
      • Status Codes
  • Stacked PRs CLI
    • Quickstart for Stacked PRs CLI
    • CLI Installation
    • How-to Guides for Stacked PRs CLI
      • How to Create Stacked PRs in CLI
      • How to Navigate & Modify Stacked PRs
      • Add Commits in the Stack
      • How Split a Commit in CLI
      • How to Split and Fold Pull Requests
      • How to Rename a Branch in CLI
      • How to Adopt a Branch in CLI
      • Orphan a Branch with Aviator CLI
      • How to Do Git Subcommand Aliasing
      • How to Create an Access Token
      • How to Set Up Auto Completion in CLI
      • How to Use Editor Plugins in CLI
    • Concepts for StackedPRs CLI
    • How to Rebase and Sync with GitHub
    • Configuration for StackedPRs CLI
    • Stacked PRs FAQs and Troubleshooting
      • Working with Aviator CLI
      • Default Branch Update Master to Main
    • Manpages for Stacked PRs CLI
      • av(1)
      • av-adopt Command Guide
      • av-auth-status(1) in CLI
      • av-stack-branch(1) in CLI
      • av-commit-create(1) in CL
      • av-stack-diff(1) in CLI
      • av-fetch(1) in CLI
      • av-git-interaction Command Guide
      • av-init(1) in CLI
      • av-stack-next(1) in CLI
      • av-orphan Command Guide
      • av-pr-status(1) in CLI
      • av-pr-create(1) in CLI
      • av-stack-prev(1) in CLI
      • av-stack-reorder(1) in CLI
      • av-reparent Command Guide
      • av-restack Command Guide
      • av-commit-split(1) in CLI
      • av-switch Command Guide
      • av-stack-sync(1) in CLI
      • av-stack-tidy(1) in CLI
      • av-stack-tree(1) in CLI
    • Aviator CLI Major Releases
      • Aviator CLI v0.1.0 Release Notes
  • Aviator's Chrome Extension
  • Pilot Automated Actions
    • Scheduled Events
    • JavaScript Execution
    • Pilot Automated Actions Reference
      • GitHub Reference
      • MergeQueue Reference
      • Slack Reference
  • API and Integrations
    • Slack Integration Guide
    • GraphQL API Quickstart
    • Prometheus Metrics Setup for GCP
    • Reference
      • JSON API
      • GraphQL
      • Webhooks
      • Monitoring Metrics
  • Manage
    • Access Management
    • GitHub App Permissions
    • Security
      • Aviator Agents Data Usage & Retention Policy
    • On-Premise Installation
      • GitHub App for On-Prem
      • GitHub OAuth for On-Prem
      • Use Helm Instructions
      • Use Docker Compose Instructions
      • Prometheus endpoint
      • Slack Integration for On-Premise
      • Google SSO Login for On-Prem
    • FAQs
      • Troubleshooting GitHub app connection
      • MergeQueue FAQs
      • Billing FAQs
Powered by GitBook
On this page
  • GitHub CODEOWNERS file
  • Aviator OWNERS file and distributed aviator-config.yaml
  • Aviator OWNERS file
  • aviator-config.yaml
  • Common owners for cross-team code review

Was this helpful?

  1. FlexReview
  2. Concepts for FlexReview

Recursive Ownership in FlexReview

Learn how recursive ownership enhances code review workflows by assigning ownership dynamically in FlexReview.

PreviousRead-Only Mode in FlexReviewNextReviewer suggestion and assignment

Last updated 1 month ago

Was this helpful?

GitHub defines . However, its semantics is not expressive enough to capture the actual shape of code ownership. We define a new format to define ownership for the codebase.

GitHub CODEOWNERS file

GitHub's CODEOWNERS file uses the last-matching rule. When one file matches with multiple lines in the file, the last one takes the precedence and other entries are not in effect. For example, imagine that you have following CODEOWNERSfile.

# CODEOWNERS
src             @acme-corp/engineering
src/ios         @acme-corp/ios-eng
src/ios/auth    @acme-corp/ios-auth-eng
src/ios/net     @acme-corp/ios-net-eng

If you modify files in src/ios/authand src/ios/net, your PR needs an approval from two teams due to the last-matching rule. However, based on the file paths, it could have had a reviewer from @ios-eng because all the files are under src/ios.

The format allows you to put multiple teams on one line. By using this, you can put @ios-eng to all child directory entries to see if it can minimize the number of reviewers. This ends up in picking a reviewer from each team.

For this reason, we see that CODEOWNERS not flexible enough.

When using FlexReview with just the CODEOWNERS file, Aviator reviewer assignment should still work within the CODEOWNERS bounds. If there are multiple teams assigned on a single line, Aviator will only choose reviewers from the first team.

Aviator OWNERS file and distributed aviator-config.yaml

These optional owner configuration files enhance FlexReview's capabilities by providing more flexibility than the traditional CODEOWNERS file.

To address the limitations of the CODEOWNERS file, we introduce two optional files:

  • .aviator/OWNERS

  • aviator-config.yaml

Aviator OWNERS file

The .aviator/OWNERS file follows a similar format to GitHub's CODEOWNERS but allows only one team per line. However, ownership interpretation differs:

  • Owners: All matching teams are considered owners of a file.

  • Direct Owners: The team with the longest matching path.

  • Indirect Owners: All other matching teams except the direct owner.

Example:

# .aviator/OWNERS
src             @acme-corp/engineering
src/ios         @acme-corp/ios-eng
src/ios/auth    @acme-corp/ios-auth-eng
src/ios/net     @acme-corp/ios-net-eng

For a file under src/ios/auth, the ownership is:

  • Owners: @engineering, @ios-eng, @ios-auth-eng

  • Direct Owners: @ios-auth-eng

  • Indirect Owners: @engineering, @ios-eng

FlexReview recognizes ownership recursively based on directory structure.

aviator-config.yaml

The aviator-config.yaml file provides an alternative way to configure ownership with a structured format and can be placed in any directory within the repository.

Example:

# src/ios/aviator-config.yaml
owners:
  - team: "acme-corp/ios-eng"
  - team: "acme-corp/ios-auth-eng"
    paths:
      - "auth"
  - team: "acme-corp/ios-net-eng"
    paths:
      - "net"

# src/aviator-config.yaml
owners:
  - team: "acme-corp/engineering"
  • The paths field is optional; if omitted, all files in the directory (recursively) belong to the specified team.

  • Paths are interpreted relative to the directory containing aviator-config.yaml.

  • Ownership follows the most specific path match, similar to .aviator/OWNERS.

Choosing a Format

For initial onboarding, we recommend starting with .aviator/OWNERS since it closely resembles GitHub's CODEOWNERS file, making adoption easier.

Over time, you can transition to aviator-config.yaml files. This approach allows teams to manage their ownership independently and ensures ownership information moves along with the code when it is relocated.

By leveraging these files, FlexReview provides a scalable and flexible way to define ownership in your repository.

Common owners for cross-team code review

When a PR modifies files owned by different direct owners, FlexReview tries to find a common owner. Let's say a PR modifies files under src/ios/authand src/ios/net. The related owners are inferred as this:

  • Owners: @engineering, @ios-eng, @ios-auth-eng, @ios-net-eng

  • Direct Owners: @ios-auth-eng, @ios-net-eng

  • Indirect Owners: @engineering, @ios-eng

If there are more than one direct owner for a PR, FlexReview tries to find the common owner based on the file paths. In this case, @ios-eng is the common owner of both teams, and it will assign a reviewer from that team.

CODEOWNERS config