mirror of
https://we.phorge.it/source/phorge.git
synced 2025-03-28 12:08:14 +01:00
ae54af32c1
Summary: Depends on D20129. Ref T13244. See PHI1058. When a revision has an "Accept" from a package, count the owners as "involved" in the change whether or not any actual human owners are actually accepting reviewers. If a user owns "/" and uses "force accept" to cause "/src/javascript" to accept, or a user who legitimately owns "/src/javascript" accepts on behalf of the package but not on behalf of themselves (for whatever reason), it generally makes practical sense that these changes have owners involved in them (i.e., that's what a normal user would expect in both cases) and don't need to trigger audits under "no involvement" rules. Test Plan: Used `bin/repository reparse --force --owners <commit>` to trigger audit logic. Saw a commit owned by `O1` with a revision counted as "involved" when `O1` had accepted the revision, even though no actual human owner had accepted it. Reviewers: amckinley Reviewed By: amckinley Maniphest Tasks: T13244 Differential Revision: https://secure.phabricator.com/D20130
181 lines
6.7 KiB
Text
181 lines
6.7 KiB
Text
@title Owners User Guide
|
|
@group userguide
|
|
|
|
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.)
|