Lightweight code review of changesets

Notice: This plugin is unmaintained and available for adoption.

Description

This plugin integrates code review functionality into Trac. Comments can be added to a changeset from the /changeset page.

This plugin simplifies source controlled software development by permitting any authorized user to submit changes to the code repository, rather than requiring all approved changes to be merged manually by the project maintainer. This functionality enables a more centralized usage of your code repository.

JavaScript is required.

This plugin comes with its own CommitTicketReferenceMacro, which can be optionally used instead of the built-in one to display the current status within the ticket:

When a review summary is provided, it gets added as a comment to all tickets referenced in the changeset (also shown above).

This plugin is inspired by ​Gerrit, which itself is Apache licensed. This tool would have to be reworked substantially to neatly integrate it into existing Trac tools and ticket workflow. When this plugin was started, the few existing Trac-based code review plugins appeared to be unmaintained. And so this plugin was born.

See also:

• CodeCommentsPlugin Comment on deliverables and link to tickets
• CodeReviewPlugin Code review of changesets
• CodeReviewerPlugin Lightweight code review of changesets
• ExoWebCodeReviewPlugin Apply code reviews to changesets
• PeerReviewPlugin Distributed Peer Review of Source Code
• PeerReviewPlugin/Documentation Distributed Peer Review - User Guide

Bugs/Feature Requests

Existing bugs and feature requests for CodeReviewerPlugin are here.

If you have any issues, create a new ticket.

defect	22 / 23
enhancement	3 / 6
task	2 / 2

Download

Download the zipped source from here.

Source

You can check out CodeReviewerPlugin from here using Subversion, or browse the source​ with Trac.

The plugin is also available on ​PyPI.

Installation / Configuration

1. Install the plugin, after downloading and unzipping:

   $ cd codereviewerplugin/0.12
   $ sudo python setup.py bdist_egg
   $ sudo cp dist/TracCodeReviewer*.egg /your/trac/location/plugins/
   

   See TracPlugins for more installation details and options.
2. Enable the plugin in your trac.ini file and if using the built-in commit-updater, disable CommitTicketReferenceMacro:

   [components]
   coderev.* = enabled
   tracopt.ticket.commit_updater.committicketreferencemacro = disabled
   tracopt.ticket.commit_updater.committicketupdater = enabled
   

   You can alternatively use the Trac Web Admin GUI to enable or disable components.
3. Enable repository caching with explicit synchronization.
4. Optional: Customize the names for the three statuses and make sure there are always exactly three in the shown order of meaning:

   [codereviewer]
   status_choices = FAILED,PENDING,PASSED
   

5. After the above, upgrade your Trac environment:

   $ sudo trac-admin /path/to/projenv upgrade
   

6. Resync the repository

   $ sudo trac-admin /path/to/projenv codereviewer resync <repos>
   

See the next section for more configuration options.

Examples

There are some additional extensions this plugin offers in addition to the simplified examples shown above:

Workflow - field validation

There are many ways to integrate code reviews into your Trac ticket workflow. As just one example, you may have a phase custom field that includes different phases:

1. implementing
2. codereview
3. verifying

If you wanted to prevent the phase from moving beyond "codereview" until all pending code reviews were completed and the last changeset passed review, then if using this plugin's commit ticket reference macro you can add the following DynamicFields plugin rules:

[ticket-custom]
phase = select
phase.options = implementing|codereview|verifying
phase.invalid_if.1 = verifying
phase.invalid_when.1 = .codereviewstatus .pending (msg:Pending code reviews.)
phase.invalid_if.2 = verifying
phase.invalid_when.2 = .codereviewstatus:last .failed (msg:The last code review did not pass.)

Continuous Integration (Jenkins / Hudson / Bitten / etc.)

​Gerrit's philosophy is to treat a code review similar to a Jenkins test job, ie code changes do not get promoted to the next stage in a continuous integration / deployment pipeline until they pass a review. You can achieve this effect with this plugin via an included Reviewer​ class.

In brief, Reviewer​ accepts a target git reference, eg "develop" or "master", and its get_next_changeset() method will return the changeset that is closest to that target (since the last changeset found) whose referenced ticket(s) have been completed. A "completed" ticket is one that passed the workflow tests described above:

• the ticket has no PENDING changesets to review, and
• the ticket's last changeset PASSED review.

You can configure this plugin to trigger a Jenkins job (or any command) in trac.ini:

[codereviewer]
command = curl http://jenkins.example.com/job/stage_deploy/build?token=mytoken

In the example above, each time a code review is submitted for a completed ticket, the stage_deploy Jenkins job gets triggered. The job would then call Reviewer.get_next_changeset()​ to determine what git changeset to deploy (if any). Note that this trigger for, say, a stage environment would be in addition to any trigger for running tests against the HEAD of your branch, or however you may currently have your CI system set up.

Completeness criteria

You can also add "completeness" criteria to determine when a ticket is actually complete and ready for deployment. For example, if your workflow encourages ongoing code reviews on tickets that may not be fully complete, you can specify one or more ticket fields to use as additional criteria to determine completeness in trac.ini:

[codereviewer]
completeness = phase=(codereview|verifying|releasing)

In the above example, a "complete" ticket is now defined as not only having all changesets reviewed and the last review PASSED, but also that the ticket's custom phase field has a value of either "codereview", "verifying" or "releasing".

The format of the completeness trac.ini options is a comma-delimited list of field-rule pairs where a rule is a regex that is used to match the field's value.

Workflow - ticket changes

You can have code review submissions automatically change fields of completed tickets. Continuing the workflow example from above, if a ticket's custom phase field gets set to "codereview" and reassigned to a reviewer, the reviewer may typically send the ticket back to "implementation" and the author after a failed review. The plugin can do this automatically via specifying this in trac.ini:

[codereviewer]
failed = phase=implementation,owner={author}
passed = phase=verifying,owner={author}

Upon a failed review in the above example, the ticket's phase field will get set to "implementation" and the ticket's owner field will get set to the same value as the author field, assuming there is one. The curly braces syntax indicates to copy the value from the indicated field. Similarly, a passed review will change the ticket's phase field to "verifying" and set the owner field to the author.

Note: these automated ticket changes will only happen for completed tickets following the same definition as defined above, ie all changesets are reviewed and the last review PASSED, and satisfy all completeness criteria if defined, with the exception that the last review does not need to have passed to trigger the failed ticket change rules (obviously).

Recent Changes

17726 by rjollos on 2020-05-07 01:37:59

CodeReviewerPlugin 1.0.0dev: Fixed reviewer not used in ticket change entry

Refs #13079.

17705 by rjollos on 2020-04-29 02:31:14

CodeReviewerPlugin 1.0.0dev: Publish to PyPI

Fixes #13662.

17016 by jun66j5 on 2017-12-08 03:52:54

CodeReviewerPlugin 1.0.0dev: fix ValueError raising when configuration is invalid (refs #13344)

(more)

Author/Contributors

Author: robguttman
Maintainer: none (needsadoption)
Contributors: rjollos