Changes between Version 14 and Version 15 of CodeReviewerPlugin


Ignore:
Timestamp:
May 24, 2012 3:02:50 PM (2 years ago)
Author:
robguttman
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • CodeReviewerPlugin

    v14 v15  
    4343    [codereviewer] 
    4444    status_choices = REJECTED,PENDING,PASSED 
    45     status_default = PENDING 
    4645    }}} 
    4746 
     
    7372The screenshots in the examples above show basic examples.  There are some additional extensions: 
    7473 
    75 === Workflow === 
     74=== Workflow - field validation === 
    7675There 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: 
    7776 1. implementation 
     
    8584    phase.invalid_when.1 = .codereviewstatus .pending (msg:Pending code reviews.) 
    8685    phase.invalid_if.2 = verifying 
    87     phase.invalid_when.2 = .codereviewstatus:last .rejected (msg:The last code review did not pass.) 
     86    phase.invalid_when.2 = .codereviewstatus:last .failed (msg:The last code review did not pass.) 
    8887    }}} 
    8988 
    90 === Jenkins === 
    91 tbd 
     89 
     90=== Continuous Integration (Jenkins / Hudson / Bitten / etc.) === 
     91[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. 
     92 
     93In 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., 
     94 * the ticket has no PENDING changesets to review, ''and'' 
     95 * the ticket's last changeset PASSED review. 
     96 
     97You can configure this plugin to trigger a Jenkins job (or any command) in {{{trac.ini}}}: 
     98{{{ 
     99[codereviewer] 
     100command = curl http://jenkins.example.com/job/stage_deploy/build?token=mytoken 
     101}}} 
     102 
     103In 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.) 
     104 
     105==== Completeness criteria ==== 
     106You 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}}}: 
     107{{{ 
     108[codereviewer] 
     109completeness = phase=(codereview|verifying|releasing) 
     110}}} 
     111 
     112In 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. 
     113 
     114The 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. 
     115 
     116 
     117=== Workflow - ticket changes === 
     118You 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 the review.  The plugin can do this automatically via specifying this in {{{trac.ini}}}: 
     119{{{ 
     120[codereviewer] 
     121failed = phase=implementation,owner={author} 
     122passed = phase=verifying,owner={author} 
     123}}} 
     124 
     125Upon 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. 
     126 
     127Note: 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). 
     128 
    92129 
    93130== Recent Changes ==