Infrastructure/Review Board: Difference between revisions

From KDE TechBase
(Created page with '== Using ReviewBoard and post-review with Git == A very comfortable way of posting changes for review is [http://git.reviewboard.kde.org ReviewBoard], where every project reposi...')
 
(Replaced content with "https://community.kde.org/Infrastructure/Review_Board")
 
(26 intermediate revisions by 14 users not shown)
Line 1: Line 1:
== Using ReviewBoard and post-review with Git ==
https://community.kde.org/Infrastructure/Review_Board
 
A very comfortable way of posting changes for review is [http://git.reviewboard.kde.org ReviewBoard], where every project repository has its own entry.
 
=== Creating your changeset ===
 
To create your changeset, you probably want to work in a separate branch - or even in your clone. This is actually suggested and the proper way to do changesets in Git. You can create any number of commits, amend them, and do whatever you want to do - it won't affect the next steps, as you will submit the whole branch for review.
 
Before proceeding it is good practice to rebase your branch onto the branch you want to target for the merge. So, supposing you want to target <tt>master</tt>, make sure it is up-to-date with the remote and then run, and want to publish a review for a local branch:
 
git rebase master
 
If you want to post a review for merging a non local branch, you might want to run the following:
 
git merge master
 
=== Using post-review to post changes for review ===
 
Once you are done with the above, it is time to post the changes to ReviewBoard. The easiest and most comfortable way to do that is <tt>[http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/ post-review]</tt>, a handy command line tool which takes care of creating review requests for you.
 
==== Prerequisites ====
 
The following has to be done only once to make your local clone fit for use with <tt>post-review</tt>.
 
First of all, you have to tell it about the ReviewBoard server. If your project does not ship with a <tt>.reviewboardrc</tt> file (encourage the project manager to add one!), the first thing you have to run is:
 
git config reviewboard.url https://git.reviewboard.kde.org
 
ReviewBoard currently only knows the project repositories by their git:// URLs, making it necessary to have a remote using the git:// URL in your clone. If your <tt>origin</tt> remote is already using the git:// URL, you are all set. If not you need to add another remote now.
 
Let's suppose you are looking to have some changes to [https://projects.kde.org/projects/extragear/multimedia/amarok Amarok] reviewed, and the URL of your <tt>origin</tt> remote is <tt>[email protected]:amarok</tt>. To add another remote using the git:// URL you might run:
 
git remote add anonupstream git://anongit.kde.org/amarok
git fetch anonupstream
 
If your <tt>origin</tt> remote was already using the git:// url, substitute <tt>anonupstream</tt> with <tt>origin</tt> throughout the rest of this tutorial.
 
==== Creating the review request ====
 
You are now ready to create the review request. The <tt>post-review</tt> command should look something like this:
 
post-review --parent=master --tracking-branch=anonupstream/master
 
This command tells <tt>post-review</tt> that your branch is based upon <tt>master</tt>, and it is set to track the remote branch <tt>anonupstream/master</tt>. You can also give <tt>post-review</tt> some more arguments to avoid using the web interface later - have a look at the [http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/ user manual] for more on that.
 
After the command has been run a web address will be shown in the terminal, pointing at your review request.
 
==== Updating a review request ====
 
If you need to update an existing review request you can invoke <tt>post-review</tt> with an additional <tt>-r</tt> argument, which should be the numeric id of the review request you want to update. Supposing you want to update review request 54, you would run:
 
post-review --parent=master --tracking-branch=anonupstream/master -r 54
 
==== Creating a ReviewBoard-compatible diff ====
 
In some rare cases you simply want to generate a diff and submit it to ReviewBoard later. You can do that by running:
 
post-review --parent=master -n > your-patch.patch
 
=== Closing a review request ===
 
To close a review request, you can either use the ReviewBoard web interface or more conveniently, right in a commit. This is done by using the REVIEW keyword followed by the review ID you want to close. For example, to close review 54, you would put
 
REVIEW: 54
 
in your commit. A message will also be posted to ReviewBoard indicating the commit SHA1 that closed the request.

Latest revision as of 11:39, 9 March 2016