Extension:CodeReview

MediaWiki extensions manual - list

CodeReview Release status: stable
Implementation	Special page, API
Description	Code review tool with Subversion support
Author(s)	Brion Vibber, Aaron Schulz, Alexandre Emsenhuber and Chad Horohoe
MediaWiki	1.14a
License	GNU General Public License 2.0 or later
Download	Download snapshot Subversion [Help] Browse source code View code changes
Example	MediaWiki.org
Parameters $wgSubversionProxy $wgSubversionProxyTimeout
Added rights repoadmin codereview-add-tag codereview-remove-tag codereview-post-comment codereview-set-status
Hooks used LoadExtensionSchemaUpdates UnitTestsList MakeGlobalVariablesScript
Check usage (experimental)

CodeReview extension allows to review SVN commits on a MediaWiki installation. It adds two new special pages, Special:Code and Special:RepoAdmin. The former can be accessed by everyone, the latter only by users with the repoadmin user right.

Example

MediaWiki's code review is done using this extension at: Special:Code/MediaWiki

Installation

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

1. Download the files from SVN and place them in $IP/extensions/CodeReview/
2. Add
   require_once("$IP/extensions/CodeReview/CodeReview.php");
   into your wiki's LocalSettings.php
3. Run maintenance/update.php
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 directory. 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.

User rights

By default, everyone (including anonymous users) can post comments (codereview-post-comment), set the status of a commit (codereview-set-status), add tags (codereview-add-tag) and remove them (codereview-remove-tag).

Only stewards can administrate the SVN repository (repoadmin) and access Special:RepoAdmin.

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)