Development/Gerrit: Difference between revisions

From KDE TechBase
No edit summary
Line 1: Line 1:
Gerrit runs at [https://gerrit.vesnicky.cesnet.cz/], use your KDE Identity to login in and don't forget to upload your SSH keys ([http://code.google.com/p/gerrit/issues/detail?id=1124 bugreport]).
== 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.
  • 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)