Owners User Guide

Phabricator User Documentation (Application User Guides)

Group files in a codebase into packages and define ownership.

Overview

The Owners application allows you to group files in a codebase (or across codebases) into packages. This can make it easier to reference a module or subsystem in other applications, like Herald.

Creating a Package

To create a package, choose a name and add some files which belong to the package. For example, you might define an "iOS Application" package by including these paths:

/conf/ios/
/src/ios/
/shared/assets/mobile/

Any files in those directories are considered to be part of the package, and you can now conveniently refer to them (for example, in a Herald rule) by referring to the package instead of copy/pasting a huge regular expression into a bunch of places.

If new source files are later added, or the scope of the package otherwise expands or contracts, you can edit the package definition to keep things updated.

You can use "exclude" paths to ignore subdirectories which would otherwise be considered part of the package. For example, you might exclude a path like this:

/conf/ios/generated/

Perhaps that directory contains some generated configuration which frequently changes, and which you aren't concerned about.

After creating a package, files the package contains will be identified as belonging to the package when you look at them in Diffusion, or look at changes which affect them in Diffusion or Differential.

Dominion

The Dominion option allows you to control how ownership cascades when multiple packages own a path. The dominion rules are:

Strong Dominion. This is the default. In this mode, the package will always own all files matching its configured paths, even if another package also owns them.

For example, if the package owns a/, it will always own a/b/c.z even if another package owns a/b/. In this case, both packages will own a/b/c.z.

This mode prevents users from stealing files away from the package by defining more narrow ownership rules in new packages, but enforces hierarchical ownership rules.

Weak Dominion. In this mode, the package will only own files which do not match a more specific path in another package.

For example, if the package owns a/ but another package owns a/b/, the package will no longer consider a/b/c.z to be a file it owns because another package matches the path with a more specific rule.

This mode lets you to define rules without implicit hierarchical ownership, but allows users to steal files away from a package by defining a more specific package.

For more details on files which match multiple packages, see "Files in Multiple Packages", below.

Auto Review

You can configure Auto Review for packages. When a new code review is created in Differential which affects code in a package, the package can automatically be added as a subscriber or reviewer.

The available settings allow you to take these actions:

• Review Changes: This package will be added to reviews as a reviewer. Reviews will appear on the dashboards of package owners.
• Review Changes (Blocking) This package will be added to reviews as a blocking reviewer. A package owner will be required to accept changes before they may land.
• Subscribe to Changes: This package will be added to reviews as a subscriber. Owners will be notified of changes, but not required to act.

If you select the With Non-Owner Author option for these actions, the action will not trigger if the author of the revision is a package owner. This mode may be helpful if you are using Owners mostly to make sure that someone who is qualified is involved in each change to a piece of code.

If you select the All option for these actions, the action will always trigger even if the author is a package owner. This mode may be helpful if you are using Owners mostly to suggest reviewers.

These rules do not trigger if the package has been archived.

The intent of this feature is to make it easy to configure simple, reasonable behaviors. If you want more tailored or specific triggers, you can write more powerful rules by using Herald.

Auditing

You can automatically trigger audits on unreviewed code by configuring Auditing. The available settings allow you to select behavior based on these conditions:

• No Owner Involvement: Triggers an audit when the commit author is not a package owner, and no package owner reviewed an associated revision in Differential.
• Unreviewed Commits: Triggers an audit when a commit has no associated revision in Differential, or the associated revision in Differential landed without being "Accepted".

For example, the Audit Commits With No Owner Involvement option triggers audits for commits which:

• affect code owned by the package;
• were not authored by a package owner; and
• were not accepted (in Differential) by a package owner or the package itself.

Audits do not trigger if the package has been archived.

The intent of this feature is to make it easy to configure simple auditing behavior. If you want more powerful auditing behavior, you can use Herald to write more sophisticated rules.

Ignored Attributes

You can automatically exclude certain types of files, like generated files, with Ignored Attributes.

When a package is marked as ignoring files with a particular attribute, and a file in a particular change has that attribute, the file will be ignored when computing ownership.

(This feature is currently rough, only works for Differential revisions, and may not always compute the correct set of owning packages in some complex cases where it interacts with dominion rules.)

Files in Multiple Packages

Multiple packages may own the same file. For example, both the "Android Application" and the "iOS Application" packages might own a path like this, containing resources used by both:

/shared/assets/mobile/

If both packages own this directory, files in the directory are considered to be part of both packages.

Packages do not need to have claims of equal specificity to own files. For example, if you have a "Design Assets" package which owns this path:

/shared/assets/

...it will also own all of the files in the mobile/ subdirectory. In this configuration, these files are part of three packages: "iOS Application", "Android Application", and "Design Assets".

(You can use an "exclude" rule if you want to make a different package with a more specific claim the owner of a file or subdirectory. You can also change the Dominion setting for a package to let it give up ownership of paths owned by another package.)