- 1 Getting Started
- 2 Nice Tweaks
- 3 BoF at Akademy
- 4 Sysadmin Stuff
- 5 TODO list
Gerrit is a tool for web-based code review -- similar to ReviewBoard, but better in many ways.
Patches can be uploaded for review by any KDE user (users and developers alike). Here are a couple of one-time fixes to get you started. We will assume that your repository is already cloned from KDE (FIXME: do we want to prefer clones from Gerrit for some reason? I don't think so.)
# At first, let's add a new git remote git remote add gerrit ssh://YourKdeIdentityUsername@gerrit.vesnicky.cesnet.cz:29418/RepositoryName # Gerrit needs a client-side hook for putting the Change-Id tags into commit messages scp -p -P 29418 YourKdeIdentityUsername@gerrit.vesnicky.cesnet.cz:hooks/commit-msg .git/hooks/
Submitting Changes: git gpush
There are a couple of options of how to use Gerrit from now on. The first one is to use a handy script by Qt's developers. FIXME: http://lists.qt-project.org/pipermail/development/2012-April/003427.html
Submitting Changes: Manual Setup
Another option is doing everything by hand. Simply make commits and when you're done, push them to a "magic ref". Instead of doing stuff like git push gerrit master, you do:
git push gerrit master:refs/for/master
If you're working on a local feature branch, you can achieve a similar result by something like this:
git push gerrit HEAD:refs/for/master
The key point is the refs/for/ prefix. This is a magic ref, or a magic branch. It does not really exist, but whenever you push to it, Gerrit notices that you want to update or create a new patch/change/request/... and do the right thing.
Gerrit will tell you what has happened -- either everything went well and then you got a link to a change request on the web, or something broke and then you should get an error message about what was it.
git push gerrit HEAD:refs/for/master%[email protected],[email protected],[email protected]
As usual, the git gpush thingy is more user friendly, supports not only e-mails but also nicks, etc.
See the guide at Gerrit's website for a basic tutorial. Any registered user can give a +1 .. -1 for Code Review. KDE developers can give +2 .. -2 for any review request. At least one +2 and zero -2s are needed for a change to be submittable.
Just amend/rebase/modify-in-any-other-way your commit and push to refs/for/targetBranchName. As long as the Change-Id line in the commit is preserved, Gerrit will do the right thing and notice that it's an updated version of an existing change.
Go to settings, add a project, and then make sure all checkboxes are ticked. The default operation adds a project to your watchlist, but no events would be delivered to you :(.
Please note that this is a pretty recent version of Gerrit which differs in a few ways from the version used by e.g. the Qt project. Most of the changes are in the UI, e.g. to apply stuff locally, use the Download menu at the top-right corner of the change view.
Getting Information About Review through Git
Once a change is approved and submitted to git, Gerrit automatically inserts a proper note about that into git. Here's how to enable showing of them. At first, configure git so that it gets fetched automatically (assuming origin is your KDE remote, and that at least one change has been already merged:
git config --add remote.origin.fetch refs/notes/review:refs/notes/review git fetch origin
To show this information, add a fancy argument to e.g. git log:
$ git log --notes=review commit 39f98861cec1cba192171b6ad998328b16106c46 Author: Jan Kundrát <[email protected]> Date: Sat Sep 6 17:30:57 2014 +0200 tests: Improve debugging for extra unexpected child tasks I can as well just leave this in instead of removing it every time I hit a failure in the subsequent QVERIFY. Change-Id: Ia4a7c72d0193827e013bfe3d47a0bd7a99567058 Notes (review): Code-Review+2: Jan Kundrát <[email protected]> Submitted-by: Jan Kundrát <[email protected]> Submitted-at: Mon, 08 Sep 2014 09:19:44 +0200 Reviewed-on: https://gerrit.vesnicky.cesnet.cz/r/11 Project: trojita Branch: refs/heads/master
Doing Pushes the Fancy Way
If you dislike the refs/for/ prefix, you can set up gerrit so that you can push "directly to branch", yet git will do the right thing for you:
git config remote.gerrit.push refs/heads/*:refs/for/* git push gerrit
As Gerrit is based on git, there is a ton of possible workflows. Maybe we should settle on one and thoroughly document it?
What tricks do you find neat?
BoF at Akademy
Someone suggested to use Frameworks Meeting (Room 1 - September 9th, afternoon).
Also the PIM one (Room 4 - September 9th, morning)
The name of the project repository at KDE's git and in gerrit have to match. One can only add regular project repositories, not personal clones or scratch repos.
At first, setup the project in Gerrit:
ssh -p 29418 gerrit.vesnicky.cesnet.cz gerrit create-project --parent sysadmin/gerrit-kde-traditional-projects NameOfGitRepo
Now set up KDE's infrastructure so that any pushes propagate to Gerrit:
cd kde/repo-management # do an equivalent of commit 6bd604f73902d9a14c05a2abb88da5e1838ce2ea echo ssh://[email protected]:29418/YourRepoName > repo-configs/remote-update/YourRepoName.git git commit -a git push
At this point, you can either wait for any push to KDE's git, or push the data yourself. The manual options needs special access, though. Do not push to refs/for/*, do something like git push gerrit master:refs/heads/master and git push gerrit --tags.
How Stuff Works
Everything was deployed to CESNET's cluster within the XIFI project. The VM runs within OpenStack, and everything is deployed by Puppet. Ask jkt for details, full release is pending.
- Documentation: Write a howto for users/developers
- Define how to get support
- sysadmin's tickets?
- gerrit admins have to be able to read these
- Anything which needs hard-core stuff like recreating the whole VM: a sysadmin should file a ticket at CESNET's XIFI support. Any user who does that will be shot.
- sysadmin's tickets?
- give access to additional admins
- Frederik Gladhorn -- done
- Ben Cooksley -- done
- Who else? Register at Gerrit, send a mail to jkt and I'll make it happen.
- take care of regular backups
- PostgreSQL DB
- git's refs/changes/*
- Implement the CI
- Jenkins, its job builder, zuul,...
- Tool idea: run krazy over submitted patches before committing and inform committer about possible changes
- Get SSH keys from LDAP (bugreport)