Changes between Version 19 and Version 20 of CodeReviewerPlugin


Ignore:
Timestamp:
Apr 17, 2015, 8:52:58 AM (9 years ago)
Author:
figaro
Comment:

Cosmetic changes

Legend:

Unmodified
Added
Removed
Modified

  • CodeReviewerPlugin

    v19 v20  
    11[[PageOutline(2-5,Contents,pullout)]]
    22
    3 = Lightweight code review of changesets =
     3= Lightweight code review of changesets
    44
    5 == Description ==
     5== Description
    66
    7 This plugin adds a lightweight means to review changesets directly on existing changeset pages.  (!JavaScript is required.)
     7This plugin adds a lightweight means to review changesets directly on existing changeset pages. !JavaScript is required.
    88
    99[[Image(review1.png)]]
    … …  
    1515When a review summary is provided, it gets added as a comment to all tickets referenced in the changeset (also shown above).
    1616
    17 There are other good code review tools out there that I've used (e.g., [http://code.google.com/p/gerrit/ gerrit]) but I wanted something very lightweight that fits well into existing Trac tools and ticket workflow.  The few existing Trac-based code review plugins (below) appear to be unmaintained. And so this plugin was born.
     17There are other good code review tools out there that I've used (e.g., [http://code.google.com/p/gerrit/ gerrit]) but I wanted something very lightweight that fits well into existing Trac tools and ticket workflow. The few existing Trac-based code review plugins (below) appear to be unmaintained. And so this plugin was born.
    1818
    1919See also: CodeReviewPlugin, PeerReviewPlugin, ExoWebCodeReviewPlugin
     20
     21== Bugs/Feature Requests ==
     22
     23Existing bugs and feature requests for CodeReviewerPlugin are
     24[report:9?COMPONENT=CodeReviewerPlugin here].
     25
     26If you have any issues, create a
     27[http://trac-hacks.org/newticket?component=CodeReviewerPlugin&owner=robguttman new ticket].
     28
     29[[TicketQuery(component=CodeReviewerPlugin&group=type,format=progress)]]
     30
     31== Download ==
     32
     33Download the zipped source from [download:codereviewerplugin here].
     34
     35== Source ==
     36
     37You can check out CodeReviewerPlugin from [http://trac-hacks.org/svn/codereviewerplugin here] using Subversion, or [source:codereviewerplugin browse the source] with Trac.
    2038
    2139== Configuration ==
    … …  
    5775See the examples section [wiki:CodeReviewerPlugin#Examples below] for more configuration options.
    5876 
    59 == Bugs/Feature Requests ==
     77== Examples ==
    6078
    61 Existing bugs and feature requests for CodeReviewerPlugin are
    62 [report:9?COMPONENT=CodeReviewerPlugin here].
    63 
    64 If you have any issues, create a
    65 [http://trac-hacks.org/newticket?component=CodeReviewerPlugin&owner=robguttman new ticket].
    66 
    67 == Download ==
    68 
    69 Download the zipped source from [download:codereviewerplugin here].
    70 
    71 == Source ==
    72 
    73 You can check out CodeReviewerPlugin from [http://trac-hacks.org/svn/codereviewerplugin here] using Subversion, or [source:codereviewerplugin browse the source] with Trac.
    74 
    75 == Examples ==
    7679The screenshots in the examples above show basic examples.  There are some additional extensions:
    7780
    78 === Workflow - field validation ===
     81=== Workflow - field validation
     82
    7983There 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:
    8084 1. implementation
    … …  
    9296    }}}
    9397
     98=== Continuous Integration (Jenkins / Hudson / Bitten / etc.)
    9499
    95 === Continuous Integration (Jenkins / Hudson / Bitten / etc.) ===
    96 [http://code.google.com/p/gerrit/ Gerrit's] philosophy is to treat a code review similar to a Jenkins test job - i.e., 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 [browser:codereviewerplugin/0.12/coderev/util/reviewer.py Reviewer] class.
     100[http://code.google.com/p/gerrit/ 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 [browser:codereviewerplugin/0.12/coderev/util/reviewer.py Reviewer] class.
    97101
    98 In brief, [browser:codereviewerplugin/0.12/coderev/util/reviewer.py Reviewer] accepts a target git reference (e.g., "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 - i.e.,
     102In brief, [browser:codereviewerplugin/0.12/coderev/util/reviewer.py Reviewer] accepts a target git reference (e.g., "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 - i.e.,
    99103 * the ticket has no PENDING changesets to review, ''and''
    100104 * the ticket's last changeset PASSED review.
    … …  
    109113In 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 [browser:codereviewerplugin/0.12/coderev/util/reviewer.py 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 setup.)
    110114
    111 ==== Ticket-changeset map ====
    112 In order for the [browser:codereviewerplugin/0.12/coderev/util/reviewer.py Reviewer] to know all changesets that reference a given ticket, it needs a reliable ticket-changeset map.  The built-in {{{revision}}} table is unfortunately not sufficiently reliable for some version control systems (e.g., git) - this is a known issue.  So this plugin comes with its own changeset listener that manages a new {{{codereviewer_map}}} table.  For existing changesets, you can run a provided [browser:codereviewerplugin/0.12/coderev/util/sync.py sync.py] utility once to populate the table (but should not need it after that).
     115==== Ticket-changeset map
    113116
    114 ==== Completeness criteria ====
    115 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}}}:
     117In order for the [browser:codereviewerplugin/0.12/coderev/util/reviewer.py Reviewer] to know all changesets that reference a given ticket, it needs a reliable ticket-changeset map. The built-in {{{revision}}} table is unfortunately not sufficiently reliable for some version control systems (e.g., git) - this is a known issue. So this plugin comes with its own changeset listener that manages a new {{{codereviewer_map}}} table. For existing changesets, you can run a provided [browser:codereviewerplugin/0.12/coderev/util/sync.py sync.py] utility once to populate the table (but should not need it after that).
     118
     119==== Completeness criteria
     120
     121You 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}}}:
    116122{{{
    117123#!ini
    … …  
    124130The 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.
    125131
     132=== Workflow - ticket changes
    126133
    127 === Workflow - ticket changes ===
    128134You 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}}}:
    129135{{{
    … …  
    138144Note: these automated ticket changes will only happen for ''completed'' tickets following the same definition as defined above (i.e., 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).
    139145
    140 
    141 == Recent Changes ==
     146== Recent Changes
    142147
    143148[[ChangeLog(codereviewerplugin, 3)]]
    144149
    145 == Author/Contributors ==
     150== Author/Contributors
    146151
    147152'''Author:''' [wiki:robguttman] [[BR]]
    148 '''Maintainer:''' [wiki:robguttman] [[BR]]
     153'''Maintainer:''' [[Maintainer]] [[BR]]
    149154'''Contributors:'''