|  | Gerrit Code Review - Email Notifications | 
|  | ======================================== | 
|  |  | 
|  | Description | 
|  | ----------- | 
|  |  | 
|  | Gerrit can automatically notify users by email when new changes are | 
|  | uploaded for review, after comments have been posted on a change, | 
|  | or after the change has been submitted to a branch. | 
|  |  | 
|  | User Level Settings | 
|  | ------------------- | 
|  |  | 
|  | Individual users can configure email subscriptions by editing | 
|  | watched projects through Settings > Watched Projects with the web UI. | 
|  |  | 
|  | Specific projects may be watched, or the special project | 
|  | `All-Projects` can be watched to watch all projects that | 
|  | are visible to the user. | 
|  |  | 
|  | link:user-search.html[Change search expressions] can be used to filter | 
|  | change notifications to specific subsets, for example `branch:master` | 
|  | to only see changes proposed for the master branch. | 
|  |  | 
|  | Project Level Settings | 
|  | ---------------------- | 
|  |  | 
|  | Project owners and site administrators can configure project level | 
|  | notifications, enabling Gerrit Code Review to automatically send | 
|  | emails to team mailing lists, or groups of users. Project settings | 
|  | are stored inside of the `refs/meta/config` branch of each Git | 
|  | repository, and are placed inside of the `project.config` file. | 
|  |  | 
|  | To edit the project level notify settings, ensure the project owner | 
|  | has Push permission already granted for the `refs/meta/config` | 
|  | branch. Consult link:access-control.html[access controls] for | 
|  | details on how access permissions work. | 
|  |  | 
|  | Initialize a temporary Git repository to edit the configuration: | 
|  | ==== | 
|  | mkdir cfg_dir | 
|  | cd cfg_dir | 
|  | git init | 
|  | ==== | 
|  |  | 
|  | Download the existing configuration from Gerrit: | 
|  | ==== | 
|  | git fetch ssh://localhost:29418/project refs/meta/config | 
|  | git checkout FETCH_HEAD | 
|  | ==== | 
|  |  | 
|  | Enable notifications to an email address by adding to | 
|  | `project.config`, this can be done using the `git config` command: | 
|  | ==== | 
|  | git config -f project.config --add notify.team.email team-address@example.com | 
|  | git config -f project.config --add notify.team.email paranoid-manager@example.com | 
|  | ==== | 
|  |  | 
|  | Examining the project.config file with any text editor should show | 
|  | a new notify section describing the email addresses to deliver to: | 
|  | ---- | 
|  | [notify "team"] | 
|  | email = team-address@example.com | 
|  | email = paranoid-manager@example.com | 
|  | ---- | 
|  |  | 
|  | Each notify section within a single project.config file must have a | 
|  | unique name. The section name itself does not matter and may later | 
|  | appear in the web UI. Naming a section after the email address or | 
|  | group it delivers to is typical. Multiple sections can be specified | 
|  | if different filters are needed. | 
|  |  | 
|  | Commit the configuration change, and push it back: | 
|  | ==== | 
|  | git commit -a -m "Notify team-address@example.com of changes" | 
|  | git push ssh://localhost:29418/project HEAD:refs/meta/config | 
|  | ==== | 
|  |  | 
|  | [[notify.name.email]]notify.<name>.email:: | 
|  | + | 
|  | List of email addresses to send matching notifications to. Each | 
|  | email address should be placed on its own line. | 
|  | + | 
|  | Internal groups within Gerrit Code Review can also be named using | 
|  | `group NAME` syntax. If this format is used the group's UUID must | 
|  | also appear in the corresponding `groups` file. Gerrit will expand | 
|  | the group membership and BCC all current users. | 
|  |  | 
|  | [[notify.name.type]]notify.<name>.type:: | 
|  | + | 
|  | Types of notifications to send. If not specified, all notifications | 
|  | are sent. | 
|  | + | 
|  | * `new_changes`: Only newly created changes. | 
|  | * `new_patchsets`: Only newly created patch sets. | 
|  | * `all_comments`: Only comments on existing changes. | 
|  | * `submitted_changes`: Only changes that have been submitted. | 
|  | * `abandoned_changes`: Only changes that have been abandoned. | 
|  | * `all`: All notifications. | 
|  |  | 
|  | + | 
|  | Like email, this variable may be a list of options. | 
|  |  | 
|  | [[notify.name.header]]notify.<name>.header:: | 
|  | + | 
|  | Email header used to list the destination. If not set BCC is used. | 
|  | Only one value may be specified. To use different headers for each | 
|  | address list them in different notify blocks. | 
|  | + | 
|  | * `to`: The standard To field is used; addresses are visible to all. | 
|  | * `cc`: The standard CC field is used; addresses are visible to all. | 
|  | * `bcc`: SMTP RCPT TO is used to hide the address. | 
|  |  | 
|  | [[notify.name.filter]]notify.<name>.filter:: | 
|  | + | 
|  | link:user-search.html[Change search expression] to match changes that | 
|  | should be sent to the emails named in this section. Within a Git-style | 
|  | configuration file double quotes around complex operator values may | 
|  | need to be escaped, e.g. `filter = branch:\"^(maint|stable)-.*\"`. | 
|  |  | 
|  | When sending email to a bare email address in a notify block, Gerrit | 
|  | Code Review ignores read access controls and assumes the administrator | 
|  | has set the filtering options correctly. Project owners can implement | 
|  | security filtering by adding the `visibleto:groupname` predicate to | 
|  | the filter expression, for example: | 
|  |  | 
|  | ==== | 
|  | [notify "Developers"] | 
|  | email = team-address@example.com | 
|  | filter = visibleto:Developers | 
|  | ==== | 
|  |  | 
|  | When sending email to an internal group, the internal group's read | 
|  | access is automatically checked by Gerrit and therefore does not | 
|  | need to use the `visibleto:` operator in the filter. | 
|  |  | 
|  | GERRIT | 
|  | ------ | 
|  | Part of link:index.html[Gerrit Code Review] |