The @PLUGIN@ plugin can be configured on host and on project-level:
gerrit.config file in the plugin.@PLUGIN@ subsection@PLUGIN@.config files that are stored in the refs/meta/config branches of the projectsThis page describes all available configuration parameters. For configuration recommendations please consult the config guide.
NOTE: This is the configuration that controls the behavior of the @PLUGIN@ plugin. Code owners (except global code owners) are not defined here, but in code owner config files (e.g. OWNERS files) that are stored in the source tree of the repository.
Projects inherit the configuration of their parent projects, following the chain of parent projects until the All-Projects root project is reached which inherits the configuration from gerrit.config.
Setting a single-value configuration parameter (single string, boolean, enum, int, long) for a project overrides any inherited value for this configuration parameter.
Example for single-value configuration parameters:
parent code-owners.config:
[codeOwners]
readOnly = true
overrideInfoUrl = https://owners-overrides.example.com
exemptPureReverts = true
project code-owners.config:
[codeOwners]
readOnly = false
overrideInfoUrl = https://foo.example.com/owners-overrides
fileExtension = fork
effective configuration:
[code-owners]
readOnly = false
overrideInfoUrl = https://foo.example.com/owners-overrides
fileExtension = fork
exemptPureReverts = true
In contrast to this, if a value for a multi-value / list configuration parameter is set, the value is added to the inherited value list (the inherited value list is extended, not overridden). Overriding/unsetting an inherited value list is not possible.
Example for multi-value / list configuration parameters:
parent code-owners.config:
[codeOwners]
globalCodeOwner = bot-foo@example.com
globalCodeOwner = bot-bar@example.com
exemptedUser = bot-abc@example.com
exemptedUser = bot-xyz@example.com
disabledBranch = refs/meta/config
project code-owners.config:
[codeOwners]
globalCodeOwner = bot-baz@example.com
disabledBranch =
effective configuration:
[code-owners]
globalCodeOwner = bot-foo@example.com
globalCodeOwner = bot-bar@example.com
globalCodeOwner = bot-baz@example.com
exemptedUser = bot-abc@example.com
exemptedUser = bot-xyz@example.com
disabledBranch = refs/meta/config
NOTE: Some configuration changes can lead to changes becoming stale in the change index. E.g. if an additional branch is newly exempted in gerrit.config or in the code-owners.config of a parent project, the submittability of changes for that branch in child projects may change (since they no longer require code owner approvals), but it's not feasible to reindex all affected changes when this config change is done (as config changes can potentially affect all open changes on the host and reindexing that many changes would be too expensive). In this case the affected changes will be become stale in the change index (e.g. the change index contains outdated submit records) and as a result of this you may not observe the effects of the config change on all changes immediately, but only when they have been reindexed (which happens on any modification of the changes). If needed, you may force the reindexing of a change by calling the Index Changes REST endpoint or by touching the change (e.g. by adding a comment).
plugin.@PLUGIN@.disabled : Whether the code owners functionality is disabled for the project.
If true submitting changes doesn't require code owner approvals.
This allows projects to opt-out of the code owners functionality.
Can be overridden per project by setting codeOwners.disabled in @PLUGIN@.config.
By default false.
plugin.@PLUGIN@.disabledBranch : An exact ref, a ref pattern or a regular expression to disable the code owners functionality for the matched branches.
By using a negative lookahead, it‘s possible to match all but one branches. E.g. to disable the code owners functionality for all branches except the refs/heads/master branch the following regular expression can be used: ^refs/(?!heads/master$).* For matched branches submitting changes doesn’t require code owner approvals.
This allows branches to opt-out of the code owners functionality.
Can be set multiple times.
The configured value list can be extended on project-level by setting codeOwners.disabledBranch in @PLUGIN@.config.
By default unset.
plugin.@PLUGIN@.backend : The code owners backend that should be used.
Can be overridden per project by setting codeOwners.backend in @PLUGIN@.config.
The supported code owner backends are listed at the Backends page.
By default find-owners.
NOTE: Be careful with changing this parameter as it invalidates all existing code owner config files. E.g. by changing the backend code owner configurations may now be read from different files, or even worse from the same files but with another syntax so that the existing code owner config files can no longer be parsed.
plugin.@PLUGIN@.pathExpressions : The path expression syntax that is used in code owner config files.
Can be overridden per project by setting codeOwners.pathExpressions in @PLUGIN@.config.
The supported path expression syntaxes are listed and explained at the Path Expressions page.
By default unset which means that the path expression syntax is derived from the configured code owner backend.
NOTE: Be careful with changing this parameter as it affects how path expressions in existing code owner config files are interpreted. E.g. by changing the path expression syntax existing path expressions may now match different files, or existing path expressions may no longer be valid and fail to parse, in which case they would not match anything any more.
plugin.@PLUGIN@.fileExtension : The file extension that should be used for code owner config files.
Allows to use a different code owner configuration in a fork. E.g. if the original repository uses OWNERS code owner config files (no file extension configured) one could set fork as file extension in the fork so that the fork uses OWNERS.fork files and the existing OWNERS files are ignored.
Can be overridden per project by setting codeOwners.fileExtension in @PLUGIN@.config.
By default unset (no file extension is used).
If a file extension is configured, plugin.@PLUGIN@.enableCodeOwnerConfigFilesWithFileExtensions should be set to false, as otherwise code owner config files with any file extension will be validated, which causes validation errors if code owner config files with other file extensions use a different owners syntax or reference users that do not exist on this Gerrit host.
plugin.@PLUGIN@.enableCodeOwnerConfigFilesWithFileExtensions : Whether file extensions for code owner config files are enabled.
If enabled, code owner config files with file extensions are treated as regular code owner config files. This means they are validated on push/submit (if validation is enabled) and can be imported by other code owner config files (regardless of whether they have the same file extension or not).
Enabling this option should not be used in combination with the plugin.@PLUGIN@.fileExtension option as that option uses file extensions to differentiate different sets of code owner config files in the same repository/branch which may use different code owner syntaxes or reference users that do not exist on this Gerrit host. In this case, code owner config files with (other) file extensions should not be validated as they likely will fail the validation.
Can be overridden per project by setting codeOwners.enableCodeOwnerConfigFilesWithFileExtensions in @PLUGIN@.config.
By default false.
plugin.@PLUGIN@.overrideInfoUrl : A URL for a page that provides host-specific information about how to request a code owner override.
The frontend displays a link to this page on the change screen so that users can discover the override instructions easily.
Can be overridden per project by setting codeOwners.overrideInfoUrl in @PLUGIN@.config.
By default unset (no override info URL).
plugin.@PLUGIN@.invalidCodeOwnerConfigInfoUrl : A URL for a page that provides host-specific information about how to deal with invalid code owner config files.
This URL is included into error messages that indicate invalid code owner config files.
Can be overridden per project by setting codeOwners.invalidCodeOwnerConfigInfoUrl in @PLUGIN@.config.
By default unset (no invalid code owner config info URL).
plugin.@PLUGIN@.enableImplicitApprovals : Whether an implicit code owner approval from the change owner is assumed.
Implicit code owner approvals are only applied on patch sets that are uploaded by the change owner (change owner == last patch set uploader).
Can be FALSE, TRUE or FORCED.FALSE:
Implicit code-owner approvals of change owners are disabled.TRUE:
Implicit code-owner approvals of change owners are enabled, but only if the configured required label is not configured to ignore self approvals from the uploader.FORCED:
Implicit code-owner approvals of change owners are enabled, even if the configured required label disallows self approvals.
If enabled/enforced, code owners need to be aware of their implicit approval when they upload new changes for other users (e.g. if a contributor pushes a change to a wrong branch and a code owner helps them to get it rebased onto the correct branch, the rebased change has implicit approvals from the code owner, since the code owner is the change owner).
If implicit code owner approvals are disabled, code owners can still self-approve their own changes by voting on the change.
Can be overridden per project by setting codeOwners.enableImplicitApprovals in @PLUGIN@.config.
By default FALSE.
plugin.@PLUGIN@.enableStickyApprovals : Whether code owner approvals should be sticky on the files they approve, even if these files are changed in follow-up patch sets.
With this setting previous code owner approvals on files only get invalidated if the approval is revoked, changed (e.g. from Code-Review+1 to Code-Review-1) or re-applied, but not by the upload of a new patch set regardless of whether the new patch sets changes these files.
Code owner approvals are sticky per file but not on change level. This means they do not show up as (copied) approvals on the change screen like regular sticky approvals, but only count for the computation of the code owner file statuses. In contrast to this setting, making code owner approvals sticky on change level (by setting a copy condition on the label that is used for code owner approvals) would make the sticky approvals count for all files in the current patch set that are owned by the approvers, regardless of whether these files existed in the patch sets that were originally approved.
Since code owner approvals that are sticky on file level are not shown in the UI, users need to inspect the per-file code owner statuses to know which files are code owner approved.
Example:
If patch set 1 contains the files A, B and C and a user that owns the files A and B approves the patch set by voting with Code-Review+1, A and B are code owner approved for this patch set and all future patch sets unless the approval is revoked, changed or re-applied. This means if a second patch set is uploaded that touches files A and B, A and B are still code owner approved. If a third patch set is uploaded that adds file D that is also owned by the same code owner, file D is not code owner approved since it is not present in patch set 1 on which the user applied the code owner approval. If the user changes their vote on patch set 3 from Code-Review+1 to Code-Review-1, the new vote invalidates the approval on patch set 1, so that in this example the files A and B would no longer be code owner approved by this user. If the user re-applies the Code-Review+1 approval now all owned files that are present in the current patch set, files A, B and D, are code owner approved.
Enabling sticky code owner approvals on file level can improve the overall developer productivity significantly, since it makes re-approvals on new patch sets unecessary in many cases. With sticky code owner approvals on files new patch sets only need to be re-approved if they touch additional files, and then only by the users that own these files. In contrast to this, if code owner approvals are not sticky (neither on file level via this setting, nor on change level via a copy condition) a new patch set must always be re-approved by all code owners that approved any of the contained files, no matter if these files are touched in the new patch set.
Can be overridden per project by setting codeOwners.enableStickyApprovals in @PLUGIN@.config.
By default false.
plugin.@PLUGIN@.globalCodeOwner : The email of a user that should be a code owner globally across all branches.
If global code owners should be omitted in the code owner suggestion (e.g. because they are bots and cannot react to review requests), they can be added to the Service Users group (since members of this group are not suggested as code owners).
Can be specified multiple times to set multiple global code owners.
The configured value list can be extended on project-level by setting codeOwners.globalCodeOwner in @PLUGIN@.config.
By default unset (no global code owners).
plugin.@PLUGIN@.exemptedUser : The email of a user that should be exempted from requiring code owner approvals.
If a user is exempted from requiring code owner approvals patch sets that are uploaded by this user are automatically code-owner approved.
Can be specified multiple times to exempt multiple users.
The configured value list can be extended on project-level by setting codeOwners.exemptedUser in @PLUGIN@.config.
By default unset (no exempted users).
plugin.@PLUGIN@.readOnly : Whether code owner config files are read-only.
Can be overridden per project by setting codeOwners.readOnly in @PLUGIN@.config.
By default false.
plugin.@PLUGIN@.exemptPureReverts : Whether pure revert changes are exempted from needing code owner approvals for submit.
Only works for pure reverts which have been created through the Gerrit REST API (but not for pure reverts which were done locally and then pushed to Gerrit).
Can be overridden per project by setting codeOwners.exemptPureReverts in @PLUGIN@.config.
By default false.
plugin.@PLUGIN@.enableValidationOnBranchCreation : Policy for validating code owner config files when a branch is created. If the validation is on all code owner config files that are contained in the commit on which the branch is being created are validated. Doing this is rather expensive and will make branch creations significantly slower (in average a latency increase of 10s to 20s is expected).
Can be TRUE, FALSE, DRY_RUN, FORCED or FORCED_DRY_RUN.TRUE:
The code owner config file validation is enabled and the creation of branches that contain invalid code owner config files is rejected.
If the code owners functionality is disabled, no validation is performed.FALSE:
The code owner config file validation is disabled, the creation of branches that contain invalid code owner config files is not rejected.DRY_RUN:
Code owner config files are validated on branch creation, but the creation of branches that contain invalid code owner config files is not rejected.
If the code owners functionality is disabled, no dry-run validation is performed.FORCED:
Code owner config files are validated on branch creation even if the code owners functionality is disabled.
This option is useful when the code owner config validation should be enabled as preparation to enabling the code owners functionality.FORCED_DRY_RUN:
Code owner config files are validated on branch creation even if the code owners functionality is disabled, but the creation of branches that contain invalid code owner config files is not rejected.
This option is useful when the code owner config validation should be enabled as preparation to enabling the code owners functionality.
Can be overridden per project by setting codeOwners.enableValidationOnBranchCreation in @PLUGIN@.config.
By default FALSE.
plugin.@PLUGIN@.enableValidationOnCommitReceived : Policy for validating code owner config files when a commit is received.
Can be TRUE, FALSE, DRY_RUN, FORCED or FORCED_DRY_RUN.TRUE:
The code owner config file validation is enabled and the upload of invalid code owner config files is rejected.
If the code owners functionality is disabled, no validation is performed.FALSE:
The code owner config file validation is disabled, invalid code owner config files are not rejected.DRY_RUN:
Code owner config files are validated, but invalid code owner config files are not rejected.
If the code owners functionality is disabled, no dry-run validation is performed.FORCED:
Code owner config files are validated even if the code owners functionality is disabled.
This option is useful when the code owner config validation should be enabled as preparation to enabling the code owners functionality.FORCED_DRY_RUN:
Code owner config files are validated even if the code owners functionality is disabled, but invalid code owner config files are not rejected.
This option is useful when the code owner config validation should be enabled as preparation to enabling the code owners functionality.
Should only be disabled if there is bot that validates the code owner config files in open changes as part of a pre-submit validation.
Can be overridden per project by setting codeOwners.enableValidationOnCommitReceived in @PLUGIN@.config.
By default true.
plugin.@PLUGIN@.enableValidationOnSubmit : Policy for validating code owner config files when a change is submitted.
Can be TRUE, FALSE, DRY_RUN, FORCED or FORCED_DRY_RUN.TRUE:
The code owner config file validation is enabled and the submission of invalid code owner config files is rejected.
If the code owners functionality is disabled, no validation is performed.FALSE:
The code owner config file validation is disabled, invalid code owner config files are not rejected.DRY_RUN:
Code owner config files are validated, but invalid code owner config files are not rejected.
If the code owners functionality is disabled, no dry-run validation is performed.FORCED:
Code owner config files are validated even if the code owners functionality is disabled.
This option is useful when the code owner config validation should be enabled as preparation to enabling the code owners functionality.FORCED_DRY_RUN:
Code owner config files are validated even if the code owners functionality is disabled, but invalid code owner config files are not rejected.
This option is useful when the code owner config validation should be enabled as preparation to enabling the code owners functionality.
Disabling the submit validation is not recommended.
Can be overridden per project by setting codeOwners.enableValidationOnSubmit in @PLUGIN@.config.
By default false.
plugin.@PLUGIN@.rejectNonResolvableCodeOwners : Whether modifications of code owner config files that newly add non-resolvable code owners should be rejected on commit received and submit.
If true newly added non-resolveable code owners are reported as errors and the commit is rejected.
If false newly added non-resolvable code owners are only reported as warnings and the commit is not rejected.
This setting has no effect if the validation is disabled via enableValidationOnCommitReceived or enableValidationOnSubmit. Can be overridden per project by setting codeOwners.rejectNonResolvableCodeOwners in @PLUGIN@.config.
By default true.
plugin.@PLUGIN@.rejectNonResolvableImports : Whether modifications of code owner config files that newly add non-resolvable imports should be rejected on commit received an submit.
If true newly added non-resolveable imports are reported as errors and the commit is rejected.
If false newly added non-resolvable imports are only reported as warnings and the commit is not rejected.
This setting has no effect if the validation is disabled via enableValidationOnCommitReceived or enableValidationOnSubmit. Can be overridden per project by setting codeOwners.rejectNonResolvableImports in @PLUGIN@.config.
By default true.
plugin.@PLUGIN@.allowedEmailDomain : Email domain that allows to assign code ownerships to emails with this domain.
Can be specified multiple times.
Code ownerships that are assigned to emails with non-allowed domains are ignored and rejected on push.
By default unset (all email domains are allowed).
plugin.@PLUGIN@.requiredApproval : Approval that is required from code owners to approve the files in a change.
Any approval on the configured label that has a value >= the configured value is considered as code owner approval.
The required approval must be specified in the format “<label-name>+<label-value>”.
The configured label must exist for all projects for which this setting applies (all projects that have code owners enabled and for which this setting is not overridden).
If the definition of the configured label has copy rules enabled so that votes are sticky across patch sets, also the code owner approvals will be sticky.
If the definition of the configured label ignores self approvals from the uploader, any vote from the uploader is ignored for the code owners check.
Can be overridden per project by setting codeOwners.requiredApproval in @PLUGIN@.config.
By default “Code-Review+1”.
plugin.@PLUGIN@.overrideApproval : Approval that counts as override for the code owners submit check.
Any approval on the configured label that has a value >= the configured value is considered as code owner override.
The override approval must be specified in the format “<label-name>+<label-value>”.
Can be specifed multiple times to configure multiple override approvals. If multiple approvals are configured, any of them is sufficient to override the code owners submit check.
The configured labels must exist for all projects for which this setting applies (all projects that have code owners enabled and for which this setting is not overridden).
If the definition of the configured labels has copy rules enabled so that votes are sticky across patch sets, also the code owner overrides will be sticky.
If the definition of a configured label ignores self approvals from the uploader, any override vote from the uploader on that label is ignored for the code owners check.
The configured value list can be extended on project-level by setting codeOwners.overrideApproval in @PLUGIN@.config.
By default unset which means that the override functionality is disabled.
plugin.@PLUGIN@.enableExperimentalRestEndpoints : Whether experimental REST endpoints are enabled.
By default false.
plugin.@PLUGIN@.mergeCommitStrategy : Strategy that defines for merge commits which files require code owner approvals.
Can be ALL_CHANGED_FILES or FILES_WITH_CONFLICT_RESOLUTION.ALL_CHANGED_FILES:
All files which differ between the merge commmit that is being reviewed and its first parent commit (which is the HEAD of the destination branch) require code owner approvals.
Using this strategy is the safest option, but requires code owners to also approve files which have been merged automatically.
Using this strategy makes sense if the code owners differ between branches and the code owners in one branch don‘t trust what the code owners in other branches have approved, or if there are branches that do not require code owner approvals at all.FILES_WITH_CONFLICT_RESOLUTION:
Only files which differ between the merge commmit that is being reviewed and the auto merge commit (the result of automatically merging the 2 parent commits, may contain Git conflict markers) require code owner approvals.
Using this strategy means that files that have been merged automatically and for which no manual conflict resolution has been done do not require code owner approval.
Using this strategy is only recommended, if all branches require code owner approvals and if the code owners in all branches are trusted. If this is not the case, it is recommended to use the ALL_CHANGED_FILES strategy instead.
Example: If this strategy is used and there is a branch that doesn’t require code owner approvals (e.g. a user sandbox branch or an experimental branch) the code owners check can be bypassed by:
a) setting the branch that doesn‘t require code owner approvals to the same commit as the main branch that does require code owner approvals
b) making a change in the branch that doesn’t require code owner approvals
c) merging this change back into the main branch that does require code owner approvals
d) since it's a clean merge, all files are merged automatically and no code owner approval is required
Can be overridden per project by setting codeOwners.mergeCommitStrategy in @PLUGIN@.config.
By default ALL_CHANGED_FILES.
plugin.@PLUGIN@.fallbackCodeOwners : Policy that controls who should own paths that have no code owners defined. This policy only applies if the inheritance of parent code owners hasn't been explicity disabled in a relevant code owner config file and if there are no unresolved imports.
Can be NONE or ALL_USERS.NONE:
Paths for which no code owners are defined are owned by no one. This means changes that touch these files can only be submitted with a code owner override.ALL_USERS:
Paths for which no code owners are defined are owned by all users. This means changes to these paths can be approved by anyone. If implicit approvals are enabled, these files are always automatically approved. The ALL_USERS option should only be used with care as it means that any path that is not covered by the code owner config files is automatically opened up to everyone and mistakes with configuring code owners can easily happen. This is why this option is intended to be only used if requiring code owner approvals should not be enforced.
Please note that fallback code owners are not suggested as code owners in the UI.
Can be overridden per project by setting codeOwners.fallbackCodeOwners in @PLUGIN@.config.
By default NONE.
plugin.@PLUGIN@.maxPathsInChangeMessages : The @PLUGIN@ plugin lists owned paths in change messages when:
1. A code owner votes on the code owners label:
The paths that are affected by the vote are listed in the change message that is posted when the vote is applied.
2. A code owner is added as reviewer:
The paths that are owned by the reviewer are posted as a change message.
This configuration parameter controls the maximum number of paths that are included in change messages. This is to prevent that the change messages become too big for large changes that touch many files.
Setting the value to 0 disables including owned paths into change messages.
Can be overridden per project by setting codeOwners.maxPathsInChangeMessages in @PLUGIN@.config.
By default 50.
plugin.@PLUGIN@.enableAsyncMessageOnAddReviewer : When a code owner is added as a reviewer the @PLUGIN@ plugin posts a change message that lists owned paths of the code owner. This setting controls whether this change message should be posted asynchronously.
Posting these change messages asynchronously improves the latency for post review and post reviewers calls, since they do not need to wait until the owned paths are computed for all newly added reviewers (computing the owned path for a user is rather expensive).
Can be overridden per project by setting codeOwners.enableAsyncMessageOnAddReviewer in @PLUGIN@.config.
By default true.
plugin.@PLUGIN@.maxCodeOwnerConfigCacheSize : When computing code owner file statuses for a change (e.g. to compute the results for the code owners submit rule) parsed code owner config files are cached in memory for the time of the request.
This configuration parameter allows to set a limit for the number of code owner config files that are cached per request.
By default 10000.
plugin.@PLUGIN@.maxCodeOwnerCacheSize : When computing code owner file statuses for a change (e.g. to compute the results for the code owners submit rule) emails that are mentioned in relevant code owner config files need to be resolved to Gerrit accounts. The resolved code owners are cached in memory for the time of the request so that this resolution has to be done only once per email.
This configuration parameter allows to set a limit for the number of resolved code owners that are cached per request.
By default 10000.
codeOwners.disabled : Whether the code owners functionality is disabled for the project.
If true submitting changes doesn't require code owner approvals.
This allows projects to opt-out of the code owners functionality.
Overrides the global setting plugin.@PLUGIN@.disabled in gerrit.config and the codeOwners.disabled setting from parent projects.
By default false.
codeOwners.disabledBranch : An exact ref, a ref pattern or a regular expression to disable the code owners functionality for the matched branches.
By using a negative lookahead, it‘s possible to match all but one branches. E.g. to disable the code owners functionality for all branches except the refs/heads/master branch the following regular expression can be used: ^refs/(?!heads/master$).* For matched branches submitting changes doesn’t require code owner approvals.
This allows branches to opt-out of the code owners functionality.
Can be set multiple times.
Extends the global setting plugin.@PLUGIN@.disabledBranch in gerrit.config and the codeOwners.disabledBranch setting from parent projects.
By default unset.
codeOwners.backend : The code owners backend that should be used for the project.
Overrides the global setting plugin.@PLUGIN@.backend in gerrit.config and the codeOwners.backend setting from parent projects.
Can be overridden per branch by setting codeOwners.<branch>.backend.
The supported code owner backends are listed at the Backends page.
If not set, the global setting plugin.@PLUGIN@.backend in gerrit.config is used.
NOTE: Be careful with changing this parameter as it invalidates all existing code owner config files. E.g. by changing the backend code owner configurations may now be read from different files, or even worse from the same files but with another syntax so that the existing code owner config files can no longer be parsed.
codeOwners.<branch>.backend : The code owners backend that should be used for this branch.
The branch can be the short or full name. If both configurations exist the one for the full name takes precedence.
Overrides the per repository setting codeOwners.backend and the codeOwners.<branch>.backend setting from parent projects.
The supported code owner backends are listed at the Backends page.
If not set, the project level configuration codeOwners.backend is used.
NOTE: Be careful with changing this parameter as it invalidates all existing code owner config files. E.g. by changing the backend code owner configurations may now be read from different files, or even worse from the same files but with another syntax so that the existing code owner config files can no longer be parsed.
codeOwners.pathExpressions : The path expression syntax that is used in[code owner config files](user-guide.html#codeOwnerConfigFiles).\ Overrides the global setting [plugin.@PLUGIN@.pathExpressions](#pluginCodeOwnersPathExpressions) ingerrit.configand thecodeOwners.pathExpressionssetting from parent projects.\ Can be overridden per branch by setting [codeOwners.\<branch\>.pathExpressions](#codeOwnersBranchPathExpressions).\ The supported path expression syntaxes are listed and explained at the [Path Expressions](path-expressions.html) page.\ If not set, the global setting [plugin.@PLUGIN@.pathExpressions](#pluginCodeOwnersPathExpressions) ingerrit.config` is used.
NOTE: Be careful with changing this parameter as it affects how path expressions in existing code owner config files are interpreted. E.g. by changing the path expression syntax existing path expressions may now match different files, or existing path expressions may no longer be valid and fail to parse, in which case they would not match anything any more.
codeOwners.<branch>.pathExpressions : The path expression syntax that is used in code owner config files that are contained in this branch.
The branch can be the short or full name. If both configurations exist the one for the full name takes precedence.
Overrides the per repository setting codeOwners.pathExpressions and the codeOwners.<branch>.pathExpressions setting from parent projects.
The path expression syntax that is used in code owner config files.
If not set, the project level configuration codeOwners.pathExpressions is used.
NOTE: Be careful with changing this parameter as it affects how path expressions in existing code owner config files are interpreted. E.g. by changing the path expression syntax existing path expressions may now match different files, or existing path expressions may no longer be valid and fail to parse, in which case they would not match anything any more.
codeOwners.fileExtension : The file extension that should be used for the code owner config files in this project.
Allows to use a different code owner configuration in a fork. E.g. if the original repository uses OWNERS code owner config files (no file extension configured) one could set fork as file extension in the fork so that the fork uses OWNERS.fork files and the existing OWNERS files are ignored.
Overrides the global setting plugin.@PLUGIN@.fileExtension in gerrit.config and the codeOwners.fileExtension setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.fileExtension in gerrit.config is used.
If a file extension is configured, codeOwners.enableCodeOwnerConfigFilesWithFileExtensions should be set to false, as otherwise code owner config files with any file extension will be validated, which causes validation errors if code owner config files with other file extensions use a different owners syntax or reference users that do not exist on this Gerrit host.
codeOwners.enableCodeOwnerConfigFilesWithFileExtensions : Whether file extensions for code owner config files are enabled.
If enabled, code owner config files with file extensions are treated as regular code owner config files. This means they are validated on push/submit (if validation is enabled) and can be imported by other code owner config files (regardless of whether they have the same file extension or not).
Enabling this option should not be used in combination with the plugin.@PLUGIN@.fileExtension option as that option uses file extensions to differentiate different sets of code owner config files in the same repository/branch which may use different code owner syntaxes or reference users that do not exist on this Gerrit host. In this case, code owner config files with (other) file extensions should not be validated as they likely will fail the validation. Overrides the global setting plugin.@PLUGIN@.enableCodeOwnerConfigFilesWithFileExtensions in gerrit.config and the codeOwners.fileExtension setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.enableCodeOwnerConfigFilesWithFileExtensions in gerrit.config is used.\
codeOwners.overrideInfoUrl : A URL for a page that provides project-specific information about how to request a code owner override.
The frontend displays a link to this page on the change screen so that users can discover the override instructions easily.
Overrides the global setting plugin.@PLUGIN@.overrideInfoUrl in gerrit.config and the codeOwners.overrideInfoUrl setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.overrideInfoUrl in gerrit.config is used.
codeOwners.invalidCodeOwnerConfigInfoUrl : A URL for a page that provides project-specific information about how to deal with invalid code owner config files.
This URL is included into error messages that indicate invalid code owner config files.
Overrides the global setting plugin.@PLUGIN@.invalidCodeOwnerConfigInfoUrl in gerrit.config and the codeOwners.invalidCodeOwnerConfigInfoUrl setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.invalidCodeOwnerConfigInfoUrl in gerrit.config is used.
codeOwners.enableImplicitApprovals : Whether an implicit code owner approval from the change owner is assumed.
Implicit code owner approvals are only applied on patch sets that are uploaded by the change owner (change owner == last patch set uploader).
Can be FALSE, TRUE or FORCED (see plugin.@PLUGIN@.enableImplicitApprovals for an explanation of these values).
If enabled/enforced, code owners need to be aware of their implicit approval when they upload new changes for other users (e.g. if a contributor pushes a change to a wrong branch and a code owner helps them to get it rebased onto the correct branch, the rebased change has implicit approvals from the code owner, since the code owner is the change owner).
If implicit code owner approvals are disabled, code owners can still self-approve their own changes by voting on the change.
Overrides the global setting plugin.@PLUGIN@.enableImplicitApprovals in gerrit.config and the codeOwners.enableImplicitApprovals setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.enableImplicitApprovals in gerrit.config is used.
codeOwners.enableStickyApprovals : Whether code owner approvals should be sticky on the files they approve, even if these files are changed in follow-up patch sets.
For details see plugin.@PLUGIN@.enableStickyApprovals.
Overrides the global setting plugin.@PLUGIN@.enableStickyApprovals in gerrit.config and the codeOwners.enableStickyApprovals setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.enableStickyApprovals in gerrit.config is used.
codeOwners.globalCodeOwner : The email of a user that should be a code owner globally across all branches.
If global code owners should be omitted in the code owner suggestion (e.g. because they are bots and cannot react to review requests), they can be added to the Service Users group (since members of this group are not suggested as code owners).
Can be specified multiple times to set multiple global code owners.
Extends the global setting plugin.@PLUGIN@.globalCodeOwner in gerrit.config and the codeOwners.globalCodeOwner setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.globalCodeOwner in gerrit.config is used.
codeOwners.exemptedUser : The email of a user that should be exempted from requiring code owner approvals.
If a user is exempted from requiring code owner approvals patch sets that are uploaded by this user are automatically code-owner approved.
Can be specified multiple times to exempt multiple users.
Extends the global setting plugin.@PLUGIN@.exemptedUser in gerrit.config and the codeOwners.exemptedUser setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.exemptedUser in gerrit.config is used.
codeOwners.readOnly : Whether code owner config files are read-only.
Overrides the global setting plugin.@PLUGIN@.readOnly in gerrit.config and the codeOwners.readOnly setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.readOnly in gerrit.config is used.
codeOwners.exemptPureReverts : Whether pure revert changes are exempted from needing code owner approvals for submit.
Only works for pure reverts which have been created through the Gerrit REST API (but not for pure reverts which were done locally and then pushed to Gerrit).
Overrides the global setting plugin.@PLUGIN@.exemptPureReverts in gerrit.config and the codeOwners.exemptPureReverts setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.exemptPureReverts in gerrit.config is used.
codeOwners.enableValidationOnBranchCreation : Policy for validating code owner config files when a branch is created.
Can be TRUE, FALSE, DRY_RUN, FORCED or FORCED_DRY_RUN. For a description of the values see plugin.@PLUGIN@.enableValidationOnBranchCreation.
Overrides the global setting plugin.@PLUGIN@.enableValidationOnBranchCreation in gerrit.config and the codeOwners.enableValidationOnBranchCreation setting from parent projects.
Can be overriden on branch-level by setting validation.<branch>.enableValidationOnBranchCreation.
If not set, the global setting plugin.@PLUGIN@.enableValidationOnBranchCreation in gerrit.config is used.
validation.<branch>.enableValidationOnBranchCreation : Branch-level policy for validating code owner config files when a branch is created.
Applies to all branches that are matched by <branch>, which can be an exact ref name (e.g. refs/heads/master), a ref pattern (e.g. refs/heads/*) or a regular expression (e.g. ^refs/heads/stable-.*).
If a branch matches multiple validation subsections it is undefined which of the subsections takes precedence.
Overrides the project-level configuration for validating code owner config files when a branch is created that is configured by codeOwners.enableValidationOnBranchCreation.
For further details see the description of codeOwners.enableValidationOnBranchCreation.
codeOwners.enableValidationOnCommitReceived : Policy for validating code owner config files when a commit is received.
Can be TRUE, FALSE, DRY_RUN, FORCED or FORCED_DRY_RUN. For a description of the values see plugin.@PLUGIN@.enableValidationOnCommitReceived.
Should only be disabled if there is bot that validates the code owner config files in open changes as part of a pre-submit validation.
Overrides the global setting plugin.@PLUGIN@.enableValidationOnCommitReceived in gerrit.config and the codeOwners.enableValidationOnCommitReceived setting from parent projects.
Can be overriden on branch-level by setting validation.<branch>.enableValidationOnCommitReceived.
If not set, the global setting plugin.@PLUGIN@.enableValidationOnCommitReceived in gerrit.config is used.
validation.<branch>.enableValidationOnCommitReceived : Branch-level policy for validating code owner config files when a commit is received.
Applies to all branches that are matched by <branch>, which can be an exact ref name (e.g. refs/heads/master), a ref pattern (e.g. refs/heads/*) or a regular expression (e.g. ^refs/heads/stable-.*).
If a branches matches multiple validation subsections it is undefined which of the subsections takes precedence.
Overrides the project-level configuration for validating code owner config files when a commit is received that is configured by codeOwners.enableValidationOnCommitReceived.
For further details see the description of codeOwners.enableValidationOnCommitReceived.
codeOwners.enableValidationOnSubmit : Policy for validating code owner config files when a change is submitted.
Can be TRUE, FALSE, DRY_RUN, FORCED or FORCED_DRY_RUN. For a description of the values see plugin.@PLUGIN@.enableValidationOnSubmit.
Disabling the submit validation is not recommended.
Overrides the global setting plugin.@PLUGIN@.enableValidationOnSubmit in gerrit.config and the codeOwners.enableValidationOnSubmit setting from parent projects.
Can be overriden on branch-level by setting validation.<branch>.enableValidationOnSubmit.
If not set, the global setting plugin.@PLUGIN@.enableValidationOnSubmit in gerrit.config is used.
validation.<branch>.enableValidationOnSubmit : Branch-level policy for validating code owner config files when a change is submitted.
Applies to all branches that are matched by <branch>, which can be an exact ref name (e.g. refs/heads/master), a ref pattern (e.g. refs/heads/*) or a regular expression (e.g. ^refs/heads/stable-.*).
If a branches matches multiple validation subsections it is undefined which of the subsections takes precedence.
Overrides the project-level configuration for validating code owner config files when a change is submitted that is configured by codeOwners.enableValidationOnSubmit.
For further details see the description of codeOwners.enableValidationOnSubmit.
codeOwners.rejectNonResolvableCodeOwners : Whether modifications of code owner config files that newly add non-resolvable code owners should be rejected on commit received and submit.
If true newly added non-resolveable code owners are reported as errors and the commit is rejected.
If false newly added non-resolvable code owners are only reported as warnings and the commit is not rejected.
This setting has no effect if the validation is disabled via enableValidationOnCommitReceived or enableValidationOnSubmit. Overrides the global setting plugin.@PLUGIN@.rejectNonResolvableCodeOwners in gerrit.config and the codeOwners.rejectNonResolvableCodeOwners setting from parent projects.
Can be overriden on branch-level by setting validation.<branch>.rejectNonResolvableCodeOwners.
If not set, the global setting plugin.@PLUGIN@.rejectNonResolvableCodeOwners in gerrit.config is used.
validation.<branch>.rejectNonResolvableCodeOwners : Branch-level configuration to control whether modifications of code owner config files that newly add non-resolvable code owners should be rejected on commit received and submit.
Applies to all branches that are matched by <branch>, which can be an exact ref name (e.g. refs/heads/master), a ref pattern (e.g. refs/heads/*) or a regular expression (e.g. ^refs/heads/stable-.*).
If a branches matches multiple validation subsections it is undefined which of the subsections takes precedence.
Overrides the project-level configuration for rejecting non-resolvable code owners that is configured by codeOwners.rejectNonResolvableCodeOwners.
For further details see the description of codeOwners.rejectNonResolvableCodeOwners.
codeOwners.rejectNonResolvableImports : Whether modifications of code owner config files that newly add non-resolvable imports should be rejected on commit received an submit.
If true newly added non-resolveable imports are reported as errors and the commit is rejected.
If false newly added non-resolvable imports are only reported as warnings and the commit is not rejected.
This setting has no effect if the validation is disabled via enableValidationOnCommitReceived or enableValidationOnSubmit. Overrides the global setting plugin.@PLUGIN@.rejectNonResolvableImports in gerrit.config and the codeOwners.rejectNonResolvableImports setting from parent projects.
Can be overriden on branch-level by setting validation.<branch>.rejectNonResolvableImports.
If not set, the global setting plugin.@PLUGIN@.rejectNonResolvableImports in gerrit.config is used.
validation.<branch>.rejectNonResolvableImports : Branch-level configuration to control whether modifications of code owner config files that newly add non-resolvable imports should be rejected on commit received and submit.
Applies to all branches that are matched by <branch>, which can be an exact ref name (e.g. refs/heads/master), a ref pattern (e.g. refs/heads/*) or a regular expression (e.g. ^refs/heads/stable-.*).
If a branches matches multiple validation subsections it is undefined which of the subsections takes precedence.
Overrides the project-level configuration for rejecting non-resolvable imports that is configured by codeOwners.rejectNonResolvableImports.
For further details see the description of codeOwners.rejectNonResolvableImports.
codeOwners.requiredApproval : Approval that is required from code owners to approve the files in a change.
Any approval on the configured label that has a value >= the configured value is considered as code owner approval.
The required approval must be specified in the format “<label-name>+<label-value>”.
The configured label must exist for all projects for which this setting applies (all child projects that have code owners enabled and for which this setting is not overridden).
If the definition of the configured label has copy rules enabled so that votes are sticky across patch sets, also the code owner approvals will be sticky.
If the definition of the configured label ignores self approvals from the uploader, any vote from the uploader is ignored for the code owners check.
Overrides the global setting plugin.@PLUGIN@.requiredApproval in gerrit.config and the codeOwners.requiredApproval setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.requiredApproval in gerrit.config is used.
codeOwners.overrideApproval : Approval that counts as override for the code owners submit check.
Any approval on the configured label that has a value >= the configured value is considered as code owner override.
The override approval must be specified in the format “<label-name>+<label-value>”.
Can be specifed multiple times to configure multiple override approvals. If multiple approvals are configured, any of them is sufficient to override the code owners submit check.
The configured labels must exist for all projects for which this setting applies (all projects that have code owners enabled and for which this setting is not overridden).
If the definition of the configured labels has copy rules enabled so that votes are sticky across patch sets, also the code owner overrides will be sticky.
If the definition of a configured label ignores self approvals from the uploader, any override vote from the uploader on that label is ignored for the code owners check.
Extends the global setting plugin.@PLUGIN@.overrideApproval in gerrit.config and the codeOwners.overrideApproval setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.overrideApproval in gerrit.config is used.
codeOwners.mergeCommitStrategy : Strategy that defines for merge commits which files require code owner approvals.
Can be ALL_CHANGED_FILES or FILES_WITH_CONFLICT_RESOLUTION (see plugin.@PLUGIN@.mergeCommitStrategy for an explanation of these values).
Overrides the global setting plugin.@PLUGIN@.mergeCommitStrategy in gerrit.config and the codeOwners.mergeCommitStrategy setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.mergeCommitStrategy in gerrit.config is used.
codeOwners.fallbackCodeOwners : Policy that controls who should own paths that have no code owners defined. This policy only applies if the inheritance of parent code owners hasn't been explicity disabled in a relevant code owner config file and if there are no unresolved imports.
Can be NONE or ALL_USERS (see plugin.@PLUGIN@.fallbackCodeOwners for an explanation of these values).
Overrides the global setting plugin.@PLUGIN@.fallbackCodeOwners in gerrit.config and the codeOwners.fallbackCodeOwners setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.fallbackCodeOwners in gerrit.config is used.
codeOwners.maxPathsInChangeMessages : The @PLUGIN@ plugin lists owned paths in change messages when:
1. A code owner votes on the code owners label:
The paths that are affected by the vote are listed in the change message that is posted when the vote is applied.
2. A code owner is added as reviewer:
The paths that are owned by the reviewer are posted as a change message.
This configuration parameter controls the maximum number of paths that are included in change messages. This is to prevent that the change messages become too big for large changes that touch many files.
Setting the value to 0 disables including owned paths into change messages.
Overrides the global setting plugin.@PLUGIN@.maxPathsInChangeMessages in gerrit.config and the codeOwners.maxPathsInChangeMessages setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.maxPathsInChangeMessages in gerrit.config is used.
codeOwners.enableAsyncMessageOnAddReviewer : When a code owner is added as a reviewer the @PLUGIN@ plugin posts a change message that lists owned paths of the code owner. This setting controls whether this change message should be posted asynchronously.
Posting these change messages asynchronously improves the latency for post review and post reviewers calls, since they do not need to wait until the owned paths are computed for all newly added reviewers (computing the owned path for a user is rather expensive).
Overrides the global setting plugin.@PLUGIN@.enableAsyncMessageOnAddReviewer in gerrit.config and the codeOwners.enableAsyncMessageOnAddReviewer setting from parent projects.
If not set, the global setting plugin.@PLUGIN@.enableAsyncMessageOnAddReviewer in gerrit.config is used.
Back to @PLUGIN@ documentation index
Part of Gerrit Code Review