Differences between revisions 3 and 12 (spanning 9 versions)
Revision 3 as of 2010-11-15 19:41:00
Size: 2983
Editor: MalteHelmert
Comment:
Revision 12 as of 2020-07-09 08:47:09
Size: 938
Comment: code reviews
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
= Code reviews with Rietveld = = Code reviews with Github =
Line 5: Line 5:
We are using (or planning to use) the [[http://code.google.com/appengine/articles/rietveld.html|Rietveld code review tool]]. You can prepare a code review by making a pull-request in your own Fast Downward fork on Github.
Line 7: Line 7:
There are various fancy ways in which Rietveld could be integrated into our infrastructure (repository, issue tracker), such as:  * Fork the official Github repository.
 * In the fork, prepare your issue or feature branch (e.g. issue123) according to [[../Git|our Git workflow]].
 * In the fork, click "Pull requests" and click "New pull request", then select the `main` branch of '''your repository''' on the left and the `issue123` branch on the right.
 * Click "Create pull request".
 * Link to the pull request from the issue tracker.
Line 9: Line 13:
 * Hosting our own instance of Rietveld rather than [[http://codereview.appspot.com/|the one hosted by Google]].
 * Writing a Mercurial extension (or plain shell script) that automatically calls Rietveld's {{{upload.py}}} with the appropriate info for [[../Workflow|our Mercurial workflow]].
 * Writing a Roundup plugin that identifies patches that are attached to an issue and automatically creates and links a matching Rietveld issue.
 * Writing a Mercurial extension that automatically uploads a patch to Roundup attached to the appropriate issue (from where a Roundup/Rietveld integration plugin could take over). Could also go the other way: automatically fetch a patch from an issue and apply it.
 * Automatically matching up our Roundup users to Rietveld users, or automatically matching up our Mercurial users to Rietveld users (e.g. linking the nosy list of an issue to the "reviewers" of a Rietveld issue.)
== Compare arbitrary revisions ==
Line 15: Line 15:
For now, let's leave these as potential avenues to explore in the future and stick with using Rietveld manually until we've got the hang of it.

== Using Rietveld manually ==

To get set up, download Rietveld's {{{upload.py}}} with {{{
wget http://codereview.appspot.com/static/upload.py}}}
and store it somewhere on your path. Don't forget to make it executable.

To create a patch:

 1. {{{hg update}}} to the "new" version of the code that is to be reviewed. If you're working on issue1000, {{{
hg update issue1000}}} should do the trick.
 1. Find out (using {{{hg log}}}, {{{hg parents}}} etc.) which "base" version of the code this should be reviewed against. Normally this would be the parent of the first revision on your branch, which you can find out with {{{
hg parents -r $(hg log --branch issue1000 --template '{node}\n' | tail -1)}}} (Is there an easier way?) Let {{{BASE}}} be the changeset identified in this way. You can use either the local numeric id or the global hash.
 1. Optionally, run {{{
hg meld -r BASE}}} and verify that you picked the correct {{{BASE}}} revision. (If you haven't set up {{{hg meld}}} yet, see [[../Mercurial]].)
 1. Run {{{
upload.py --rev=BASE}}} to create a Rietveld issue.
 1. You'll have to answer some questions. When queried for your email and password, use ones that are tied to some Google account (e.g. that you use for Google groups); they don't have to be {{{gmail}}}/{{{googlemail}}} addresses.
 1. You'll see a line like {{{
Issue created. URL: http://codereview.appspot.com/XXXXXXX}}} that provides the URL for the newly created issue. Send it to the potential reviewer or go to that page to invite a reviewer via Rietveld's web interface.
Compare any two revisions by following the steps above but using the commit IDs of the commits you want to compare instead of the branch names. It is not possible to create a pull request this way because merging might not make sense for the selected commits but you'll be able to see the code difference.

Back to developer page.

Code reviews with Github

You can prepare a code review by making a pull-request in your own Fast Downward fork on Github.

  • Fork the official Github repository.
  • In the fork, prepare your issue or feature branch (e.g. issue123) according to our Git workflow.

  • In the fork, click "Pull requests" and click "New pull request", then select the main branch of your repository on the left and the issue123 branch on the right.

  • Click "Create pull request".
  • Link to the pull request from the issue tracker.

Compare arbitrary revisions

Compare any two revisions by following the steps above but using the commit IDs of the commits you want to compare instead of the branch names. It is not possible to create a pull request this way because merging might not make sense for the selected commits but you'll be able to see the code difference.

FastDownward: ForDevelopers/CodeReview (last edited 2020-07-09 08:47:09 by SilvanSievers)