Extension:CodeReview

MediaWiki extensions manual

CodeReview Release status: stable
Implementation	Special page, API
Description	Code review tool with Subversion support
Author(s)	Brion Vibber, Aaron Schulz, Alexandre Emsenhuber, Chad Horohoe, Sam Reed and Roan Kattouw
Latest version	1.18 (March 26, 2014 (2014-03-26))
MediaWiki	1.19+
Database changes	Yes
Tables	code_authors code_bugs code_comment code_paths code_prop_changes code_relations code_repo code_rev code_signoffs code_tags
License	GNU General Public License 2.0 or later
Download	Download snapshot (Git master) Git [?]: repo summary browse file tree commit history Changelog
Example	MediaWiki.org
Parameters $wgSubversionProxy $wgSubversionProxyTimeout $wgSubversionOptions $wgCodeReviewImportBatchSize $wgCodeReviewShuffleTagCloud $wgSubversionUser $wgSubversionPassword $wgCodeReviewENotif $wgCodeReviewCommentWatcherEmail $wgCodeReviewCommentWatcherName $wgCodeReviewDisableFollowUpNotification $wgCodeReviewImgRegex $wgCodeReviewMaxDiffSize $wgCodeReviewMaxDiffPaths $wgCodeReviewDeferredPaths $wgCodeReviewAutoTagPath $wgCodeReviewFixmePerPath $wgCodeReviewNewPerPath $wgCodeReviewUDPAddress $wgCodeReviewUDPPort $wgCodeReviewUDPPrefix $wgCodeReviewRepoStatsCacheTime $wgCodeReviewStates $wgCodeReviewProtectedStates $wgCodeReviewFlags
Added rights repoadmin codereview-use codereview-add-tag codereview-remove-tag codereview-post-comment codereview-set-status codereview-signoff codereview-associate codereview-link-user codereview-review-own
Hooks used LoadExtensionSchemaUpdates MakeGlobalVariablesScript UnitTestsList
Translate the CodeReview extension if it is available at translatewiki.net
Check usage and version matrix; code metrics
Bugs: list open list all report

CodeReview extension allows to review SVN commits on a MediaWiki installation. It adds two new special pages, Special:Code and Special:RepoAdmin. Special:Code is the main CodeReview interface, whereas the RepoAdmin special page is rarely used to create new repositories.

Example

MediaWiki's code review was historically done using this extension on this wiki (MediaWiki.org), at Special:Code/MediaWiki.

MediaWiki was converted from SVN to git, with gerrit as the main code review tool, in March 2012. As a direct result of this, the CodeReview extension is no longer maintained by the Wikimedia Foundation. The extension is still functional and perfectly usable on third-party wikis.

Installation

 Note: These instructions might be missing essential bits and pieces, feel free to improve them.

1. Download the files from Git and place them in $IP/extensions/CodeReview/
2. Add
   require_once("$IP/extensions/CodeReview/CodeReview.php");
   into your wiki's LocalSettings.php
3. Run php maintenance/update.php in terminal.
4. Installation can now be verified through your wiki's Special:Version.

To set up a repository:

1. You need to be logged in as a user with the repoadmin right (by default this means a user who is a member of the svnadmins group).
2. Browse to Special:RepoAdmin
3. Enter a repository name into the input box and press "Create" button
4. Enter the three required paths; SVN, Bugzilla and ViewVC paths. These paths should be valid URLs, not local paths. For example, http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 for SVN etc.
   • The Bugzilla path should be the full URL to display a bug, with $1 representing the bug number (e.g. http://www.example.com/path/to/bugzilla/show_bug.cgi?id=$1). This path allows bug references in your commit messages to link to the appropriate bug URL.
5. Press OK.
6. Now the repository has been created and you'll need to import SVN data to it. You can do this with the svnImport.php maintenance script in CodeReview's maintenance subdirectory. To run it, type: php svnImport.php YourRepoName
   • If you're getting various host cannot be found and such errors, adjust $wgMaxShellMemory to work around a known problem when shelling out to the 'svn' command (bugzilla:26867) or try installing the PECL svn module
   • The script is dependent on English messages from the command line SVN client. If your SVN client outputs messages in a different languages, try changing your locale variables such as LANG, LC_ALL or LANGUAGE (on Unix, type locale to see the current values).
7. After the import is done, you should be able to review commits through Special:Code/YourProjectName, where YourProjectName is the name of the project you gave in Special:RepoAdmin.

Automating updates

You can set up your Subversion repository to ping CodeReview through the MediaWiki API on commit, allowing it to stay continuously up to date.

In the repository on your SVN server there's a subdirectory hooks, in which you'll find the post-commit hook file.

Add a line something like this:

 # Hit CodeReview
 wget -q -O /dev/null --post-data="action=codeupdate&format=xml&repo=MyRepoName&rev=$2" \
   "http://wiki.example.com/api.php" &

In response to this ping, the CodeReview server will fetch all updates up to the current revision from the SVN repository.

(If wget is not available on the server, you should be able to do the same with curl but a slightly different command line. Note that you must POST the request to the API, and anonymous clients need to have permission to access the wiki and its API.)

Requirements

A working installation of the command-line SVN client is needed, and the svn PECL extension is recommended.

Parameters

Parameter name	Default value	Description
$wgSubversionProxy	false	If you can't directly access the remote SVN repo, you can set this to an offsite proxy running this fun little proxy tool: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/codereview-proxy/
$wgSubversionProxyTimeout	30	Timeout for the CodeReview proxy ($wgSubversionProxy) in seconds.
$wgSubversionOptions	'--non-interactive --trust-server-cert'	Command-line options to pass on SVN command line if SVN PECL extension isn't available and we're not using the proxy. Defaults here should allow working with both http: and https: repos as long as authentication isn't required.
$wgCodeReviewImportBatchSize	400	What is the default SVN import chunk size?
$wgCodeReviewShuffleTagCloud	false	Whether to shuffle the tag cloud (displayed at Special:Code/YourRepoName/tag).
$wgSubversionUser	false	If you are running a closed SVN, fill this with username of a user allowed to access it. Otherwise, leave it false. This is only necessary if using the shell method to access Subversion.
$wgSubversionPassword	false	If you are running a closed SVN, fill this with password of the account defined at $wgSubversionUser. Otherwise, leave it false. This is only necessary if using the shell method to access Subversion.
$wgCodeReviewENotif	false	Enable CodeReview e-mail notifications? Setting this to true "spams" committers when someone changes the commit's status, posts a comment on the commit or makes a follow-up revision to it.
$wgCodeReviewCommentWatcherEmail	false	Set this to an e-mail list to send all comments to
$wgCodeReviewCommentWatcherName	'CodeReview comments list'	Name to use in the To: header of emails to the list. Ignored if $wgCodeReviewCommentWatcherEmail isn't set
$wgCodeReviewDisableFollowUpNotification	false	Set this flag to true if you want to disable the automatic notifications to all watchers of a specific revision, when a follow-up to that revision is committed. Useful for small repos when everyone is reading the commit e-mails anyway, or if you have multiple repositories which refer to one another, which result in an unreasonable level of false positives. Note that the new revision will still be marked as a follow-up - this setting just stops the e-mail being sent.
$wgCodeReviewImgRegex	'/\.(png|jpg|jpeg|gif)$/i'	Regular expression used to determine what images can be used for client-side side-by-side comparisons.
$wgCodeReviewMaxDiffSize	500000	Maximum size of diff text before it is omitted from the revision view
$wgCodeReviewMaxDiffPaths	20	The maximum number of paths that we will perform a diff on. If a revision contains more changed paths than this, we will skip getting the diff altogether. May be set to 0 to indicate no limit.
$wgCodeReviewDeferredPaths	array()	Key is repository name. Value is an array of regexes. Any base paths matching regular expressions in these arrays will have their default status set to deferred instead of new. Helpful if you've got a part of the repository you don't care about. For example: $wgCodeReviewDeferredPaths = array( 'RepoName' => array( '/path/to/use', '/another/path/to/use' ) ); You may want to take a look at an old version of the configuration that MediaWiki.org used to use for further inspiration.
$wgCodeReviewAutoTagPath	array()	Key is repository name. Value is an array of key value pairs of the path and then tags. An array (or string, for 1 tag) of tags to add to a revision upon commit. For example: $wgCodeReviewAutoTagPath = array( 'RepoName' => array( '%^/path/to/use%' => 'sometag', '%^/another/path/to/use%' => array( 'tag1', 'tag2' ) ) );
$wgCodeReviewFixmePerPath	array()	Key is repository name. Value is an array of paths to get the 'fixme' list for. This is used to display statistics (i.e. number of revisions that are in the 'fixme' state for each of the listed paths). For example: $wgCodeReviewFixmePerPath = array( 'RepoName' => array( '/path/to/use', '/another/path/to/use' ) ); You may want to take a look at an old version of the configuration that MediaWiki.org used to use for further inspiration.
$wgCodeReviewNewPerPath	array()	Key is repository name. Value is an array of paths to get the 'new' list for. This is used to display statistics (i.e. number of revisions that are in the 'new' state for each of the listed paths). For example: $wgCodeReviewNewPerPath = array( 'RepoName' => array( '/path/to/use', '/another/path/to/use' ) ); You may want to take a look at an old version of the configuration that MediaWiki.org used to use for further inspiration.
$wgCodeReviewUDPAddress	false	UDP comment and status changes notification. See also the related core MediaWiki configuration variable, $wgRC2UDPAddress.
$wgCodeReviewUDPPort	false	UDP comment and status changes notification. See also the related core MediaWiki configuration variable, $wgRC2UDPPort.
$wgCodeReviewUDPPrefix	(empty string)	UDP comment and status changes notification. See also the related core MediaWiki configuration variable, $wgRC2UDPPrefix.
$wgCodeReviewRepoStatsCacheTime	6 * 60 * 60 (=6 hours)	How long to cache repository statistics (Special:Code/MyRepoName/stats) in seconds
$wgCodeReviewStates	array( 'new', 'fixme', 'reverted', 'resolved', 'ok', 'deferred', 'old' )	Possible states a revision can be in. A system message will still needed to be added as [[MediaWiki:Code-status-STATUSNAMEGOESHERE]].
$wgCodeReviewProtectedStates	array( 'ok', 'resolved' )	Revisions states that a user cannot change to on their own revision
$wgCodeReviewFlags	array( 'inspected', 'tested' )	List of all flags a user can mark themself as having done to a revision (the signoff feature, in other words). A system message will still needed to be added as [[MediaWiki:Code-signoff-flag-FLAGNAMEGOESHERE]].

User rights

User right name	Group which is given this right by default	Description
codereview-use	*	User right required to access (view) Special:Code, and hence its subpages. Given to everyone by default.
codereview-add-tag	user	User right required to add tags to commits.
codereview-remove-tag	user	User right required to remove tags from commits.
codereview-post-comment	user	Allows posting comments on commits.
codereview-set-status	user	Allows changing the status of a commit. Statuses are defined by the configuration variable $wgCodeReviewStates.
codereview-signoff	user	Allows to use the signoff feature. Signoff is basically advertising other reviewers that you've either inspected, tested or done both to a particular commit, and the signoff feature is meant for users who are not comfortable enough to mark the commit as OK.
codereview-associate	user	Allows managing revision associations, i.e. which commit is a follow-up to a previous commit, etc.
codereview-link-user	user	Allows to associate SVN accounts with wiki accounts (which is needed for CodeReview's e-mail functionality, so that CR knows to which address it should send the e-mail(s)).
codereview-review-own	(no group has this right by default)	User right required for users to be able to review their own commits.
repoadmin	svnadmins	Required to access Special:RepoAdmin in order to add new repositories or change existing repositories' settings. To add yourself to the new svnadmins group, which is created by the CodeReview extension, visit Special:UserRights on your wiki.

Version history

The full list of changes is available via git. The following table tries to summarize the most important changes since the extension was moved from SVN to git.

Extension version	Version control system revision	Release date	Comments
1.15	gerrit:76320	30 July 2013	Renameuser support added. Database schema change required, so if you're updating from a previous version, remember to re-run update.php (and /extensions/CodeReview/maintenance/populateCaUserColumn.php, too)!
1.14	gerrit:76282	30 July 2013	Comment nesting bug fixed (bug #46636).
1.13	gerrit:76090	26 July 2013	Minor HTML generation bug fixed.
1.12	gerrit:76083	26 July 2013	Hooked functions moved to their own file; no functional changes.
1.11	gerrit:76045	26 July 2013	Version string added. Support for custom CSS on Special:Code and its subpages via MediaWiki:CodeReview.css added (bug #16049).
	r114011	16 March 2012	Last change to CodeReview from the SVN era.

To-do

• Special:Code woo!

Usage notes

Current configuration:

• Any registered user on the wiki can post comments on bugs
• Status changes and tagging requires being in the "coder" group. Any bureaucrat or coder can designate another person as a coder. It's viral! ;)

To-do

Tags

• Implement advanced tagging system --Catrope 18:51, 2 October 2008 (UTC)

Auto info on import

• path-based tags
• keyword-based tags from commit comment
  • Hmm, sounds language dependent. Aaron 07:46, 15 October 2008 (UTC)
    • Last I checked all our commit comments are in English. ;) I'm thinking of things like say:
      • mention of "bug 1234" adds "bug 1234" keyword
      • mention of "revert" adds "revert" keyword
      • Path in 'extensions/XXX' adds 'XXX' keyword --brion 22:41, 15 October 2008 (UTC)
        • Well the UI is still in several langauges. Is it OK to just have matching like this in one? Aaron 09:01, 16 October 2008 (UTC)
          • The matching is to be done at import time, to set some keywords based on standard bits in the commit message. --brion 22:36, 29 October 2008 (UTC)
            • Bear in mind that this will catch a lot of false positives. That may or may not be acceptable, depending on the magnitude and the consequences. If there are enough that it leads to people ignoring tags because they're seen as unreliable, then this would be a very bad feature indeed. --HappyDog 11:11, 10 October 2010 (UTC)

General UI

• Basic text search
  • Although not usable for others, for Wikimedia SVN I've build a grep-based search engine on the toolserver: http://toolserver.org/~krinkle/wikimedia-svn-search/
    One can pick the path (or file), searchphrase, recursivity and if it's a big seach (ie. /trunk, /extensions) it can be enqueued in the background and it's results are cached and permalinkable. Krinkle 01:03, 28 December 2010 (UTC)
• <brion> yeah what i'd like to integrate is running of parser tests, and stick in a count of how test results changed for each rev
  • I wouldn't say for every rev, maybe only show output if test results changed between revision x and x+1? ^demon 11:57, 15 October 2008 (UTC)
    • Probably show a "+3", "-22" etc to show how many tests changed to broken or fixed in the rev. Click that to expand to show the full test results? --brion 22:42, 15 October 2008 (UTC)
      • I like that :) ^demon 15:18, 16 October 2008 (UTC)
• Message to #mediawiki on comment
  • oooh that'd be nice
  • Throw comments into RC? Might help with the IRC (has direct access to the UDP stuff then), as well as keep a better record of what's going on ^demon 11:57, 15 October 2008 (UTC)
    • RC would be good... but getting notifications into #mediawiki on freenode would be separate from the general RC IRC. We'd need to set up another bot to do it. --brion 22:38, 29 October 2008 (UTC)
      • Albeit a little late, keeping it in the normal recentchanges would make them more accessable (RecentChanges page, recentchanges api, contributions page etc.). SWMTBot's latest beta also has support for Events in the feedFilter, to for example only show edits, newpages, uploads or... perhaps codereview comments ? As long as they're easy to identify in the raw feed I can build it in the software and run it from the toolserver. On a side note though, it's 2 years later, 2010; Although CR comments are not in recentchanges, they do show up on #mediawiki reported by "codurr", and that was the original request. So perhaps this should be marked as Done. See also bug 16042 Krinkle 16:06, 1 November 2010 (UTC)
• Parse asterisks in commit messages as lists --Catrope 15:58, 28 October 2008 (UTC)
  • Perhaps just treat as wikitext so that (inter)wiki links work too ? Krinkle 01:03, 28 December 2010 (UTC)
• The "notes" field in the list view should link directly to the comments section. E.g. Clicking on the "1" in the list view for r47138 should link to Special:Code/MediaWiki/47138#code-comments -- Nickj (t) 06:11, 12 February 2009 (UTC)

RSS/Atom feeds

• Comments on commits by committer X.
• All comments.
• All revisions (all or based on a specific path).
• All unresolved revisions.
• All resolved revisions.

(Suggestions by Werdna, so probably not authoritative ;-))

ooh that's be awesome

Possible mechanism for watching, history

• Store a backing page in a special 'Code' namespace; display revision data via that instead of on Special:Code
  • Allows watch/unwatch
  • Allows storing of update and comment history as null revisions on the page
    • Which show up in recentchanges and watchlist

Done

Path search

• Individual file searches aren't working right now -- "/trunk/phase3/includes/Hooks.php/" gets that "/" appended
• Provide tag history (to show who set which tag when) --Catrope 19:01, 2 October 2008 (UTC)
• Edit token breakage (?) due to timed-out session seems to result in silent failure instead of some visible thingy.
• The "notes" field in the list view should be called "Comments" instead, to use naming that's consistent with the "status" field in the detailed view, or vice-versa (change "comments" to "notes"). Personally, I prefer "comments". -- Nickj (t) 06:11, 12 February 2009 (UTC)