Changes between Version 18 and Version 19 of CodeReviewerPlugin
- Timestamp:
- Sep 22, 2012, 7:00:23 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CodeReviewerPlugin
v18 v19 22 22 1. Install the plugin (after downloading and unzipping): 23 23 {{{ 24 #!sh 24 25 cd codereviewerplugin/0.12 25 26 sudo python setup.py bdist_egg … … 31 32 2. Enable the plugin ''and'' if using the built-in {{{commit-updater}}}, disable {{{CommitTicketReferenceMacro}}}: 32 33 {{{ 34 #!ini 33 35 [components] 34 36 tracopt.ticket.commit_updater.committicketupdater = enabled … … 41 43 3. (''optional'') Customize the names for the three statuses (make sure there are always exactly three in the shown order of meaning): 42 44 {{{ 45 #!ini 43 46 [codereviewer] 44 47 status_choices = REJECTED,PENDING,PASSED … … 47 50 4. After the above, run: 48 51 {{{ 52 #!sh 49 53 sudo trac-admin /path/to/projenv upgrade 50 54 }}} … … 80 84 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 [wiki:DynamicFieldsPlugin DynamicFields plugin] rules: 81 85 {{{ 86 #!ini 82 87 [ticket-custom] 83 88 phase.invalid_if.1 = verifying … … 97 102 You can configure this plugin to trigger a Jenkins job (or any command) in {{{trac.ini}}}: 98 103 {{{ 104 #!ini 99 105 [codereviewer] 100 106 command = curl http://jenkins.example.com/job/stage_deploy/build?token=mytoken … … 109 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}}}: 110 116 {{{ 117 #!ini 111 118 [codereviewer] 112 119 completeness = phase=(codereview|verifying|releasing) … … 121 128 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}}}: 122 129 {{{ 130 #!ini 123 131 [codereviewer] 124 132 failed = phase=implementation,owner={author}