Development/Gerrit: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
== Geting Started == | |||
Gerrit is a tool for web-based code review -- similar to [[Development/ReviewBoard|ReviewBoard]], but better in many ways. | |||
The first step is to active your account at Gerrit. Use your KDE Identity account to [https://gerrit.vesnicky.cesnet.cz/r/login/ log in]. Go into [https://gerrit.vesnicky.cesnet.cz/r/#/settings/ssh-keys Settings -> SSH Keys] and upload your public SSH key in there. | |||
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: Manual Setup === | |||
There are a couple of options of how to use Gerrit from now on. The first one is to do everything by hand. Simply make commits and when you're done, push them to a "magic ref". Instead of doing stuff like <tt>git push gerrit master</tt>, 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 <tt>'''refs/for/'''</tt> 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. | |||
== BoF at Akademy == | == BoF at Akademy == | ||
Line 24: | Line 46: | ||
** Jenkins, its job builder, zuul,... | ** Jenkins, its job builder, zuul,... | ||
** Tool idea: run krazy over submitted patches before committing and inform committer about possible changes | ** Tool idea: run krazy over submitted patches before committing and inform committer about possible changes | ||
* Get SSH keys from LDAP ([http://code.google.com/p/gerrit/issues/detail?id=1124 bugreport]) |
Revision as of 10:17, 8 September 2014
Geting Started
Gerrit is a tool for web-based code review -- similar to ReviewBoard, but better in many ways.
The first step is to active your account at Gerrit. Use your KDE Identity account to log in. Go into Settings -> SSH Keys and upload your public SSH key in there.
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: Manual Setup
There are a couple of options of how to use Gerrit from now on. The first one is to do 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.
BoF at Akademy
Someone suggested to use Frameworks Meeting (Room 1 - September 9th, afternoon).
Also the PIM one (Room 4 - September 9th, morning)
TODO list
- 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?
- tosky?
- ossi?
- 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)