From MediaWiki.org
Jump to: navigation, search
MediaWiki extensions manual
Crystal Clear action run.png

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; 19 months ago (2014-03-26))
MediaWiki 1.19+
Database changes Yes
Tables code_authors
License GNU General Public License 2.0 or later
Example MediaWiki.org


Added rights


Hooks used


Translate the CodeReview extension if it is available at translatewiki.net

Check usage and version matrix; code metrics


Open tasks · Report a bug

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[edit | edit source]

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.[1] The extension is still functional and perfectly usable on third-party wikis.

Installation[edit | edit source]

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

  • Download and place the file(s) in a directory called CodeReview in your extensions/ folder.
  • Add the following code at the bottom of your LocalSettings.php:
wfLoadExtension( 'CodeReview' );
  • Run the update script which will automatically create the necessary database tables that this extension needs.
  • YesY Done - Navigate to Special:Version on your wiki to verify that the extension is successfully installed.

To users running MediaWiki 1.24 or earlier:

The instructions above describe the new way of installing extensions using wfLoadExtension(), since MediaWiki 1.25. If you need to install this extension in earlier versions, instead of wfLoadExtension( 'CodeReview' );, you need to use:

require_once "$IP/extensions/CodeReview/CodeReview.php";

(To run an extension on an earlier release, you may need to download the version of it tagged for that release from Special:ExtensionDistributor.)

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[edit | edit source]

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[edit | edit source]

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

Parameters[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

Usage notes[edit | edit source]

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[edit | edit source]

Tags[edit | edit source]

Auto info on import[edit | edit source]

  • 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[edit | edit source]

  • 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[edit | edit source]

  • 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[edit | edit source]

  • 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

sounds like funny stories those technical things..

Done[edit | edit source]

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)

Notes[edit | edit source]

  1. Comment on bug #46636 by Andre Klapper, Wikimedia Foundation's bug wrangler