https://gerrit-review.googlesource.com/
User sign-in requires a Google Account. If you previously used a
different OpenID provider (e.g. Yahoo!) you will need to setup a new
user account.
= Sources by Git =
To clone/fetch the Gerrit repository with Git, use this URL:
https://gerrit.googlesource.com/gerrit
The sibling repositories for gwtorm, etc. are at:
https://gerrit.googlesource.com/gwtorm
https://gerrit.googlesource.com/gwtexpui
https://gerrit.googlesource.com/gwtjsonrpc
https://gerrit.googlesource.com/git-repo
These URLs access the same repository used by the Gerrit Code Review
interface and are always current. On individual change pages the
Gerrit web UI will advertise these URLs to you. (Dropping the
"-review" portion of the hostname allows the request to skip the
Gerrit specific processing logic, decreasing response time for
requests.)
= Uploading Changes =
A contributor must generate a password by visiting Settings > HTTP
Password, or directly jumping to the password generator URL in a web
browser:
https://gerrit-review.googlesource.com/new-password
Once a password has been saved to ~/.netrc, changes can be pushed for
review over HTTP:
https://gerrit-review.googlesource.com/p/gerrit
= Missing: gitweb =
The new project infrastructure does not support gitweb. Web based
source browsing is available at Google Project Hosting, but this is a
stale copy that must be manually synchronized by committers.
http://code.google.com/p/gerrit/source/browse/
= Disabled: SSH or git:// =
The new project infrastructure does not support SSH, and does not
support the git:// protocol. Access is available only by HTTP or
HTTPS. Using HTTPS is strongly recommended, but not required.
= Known Bug: Login Redirect Loop =
Like any fancy new website that uses some sort of single-sign-on
system... there is a known bug where the browser can get stuck in a
redirect loop if you have not visited the site in the past few days,
but had signed-in at least once previously.
As a work-around, delete any cookies for
gerrit-review.googlesource.com and try loading the site again. Yes we
are working on it. No, it is not an easy thing to debug or fix. Please
be patient.
= Known Bug: Upload push fails with no output =
Sometimes we have seen uploads fail with no error messages on the
client side. This is a known bug somewhere in the Gerrit or JGit
portions where the reply to the client was smaller than a configured
buffer size on the server and the reply didn't get flushed to the
client at the end of the request. I thought I had this fixed upstream
in JGit but it is still showing up sometimes in Gerrit.
Double check your committer line in the commit matches with the
contact information on your Gerrit account. Verify you have a
contributor agreement in Settings > Agreements. Try fetching current
master and rebasing your new commits on top of it. Usually its one of
these.
= Environment Status =
This is a beta environment. It is running bleeding edge Gerrit Code
Review. It is not a stock Gerrit installation. We are still shaking
out problems.
The SQL database was replaced with a NoSQL system built on top of
Google Bigtable by implementing a different database backend for
gwtorm. This backend has some interesting properties, namely it is
slower than a SQL database on the same host like most Gerrit
installations use. Long story short, please be patient with the new
environment. Response times aren't where we want them to be.
The Git repositories are stored on a hybrid solution of Google
Bigtable and the Google filesystem. Most of this backend
implementation is already available in the upstream JGit project as
the storage.dfs package. It can be quite a bit slower to upload new
commits for review, or to submit changes.
Gerrit Code Review's own Gerrit instance is now available to anyone:
https://gerrit-review.googlesource.com/
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
Thomas
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
There is a Jenkins-job on Jenkins internal-CI wich is supposed to build master of Gerrit [1]. Not sure who set this up, Luca should know more. Also, this does not provide per-commit-build-verficiation using the Gerrit-trigger plugin for Jenkins. But i guess that is a small thing to setup if it is wanted.
// peter
[1] http://ci.jenkins-ci.org/job/gerrit_master/
> -----Original Message-----
> From: repo-d...@googlegroups.com
> [mailto:repo-d...@googlegroups.com] On Behalf Of Philipp Altmann
> Sent: den 10 januari 2012 11:28
> To: Repo and Gerrit Discussion
> Subject: Re: Gerrit's own Gerrit now available
>
> Will be this Gerrit integrated with Jennkins / Hudson setup?
>
> Philipp
>
Best regards
Gustaf
Sadly no. It really needs the stream-event & review-cmd functionality of Gerrit.
I guess we won't have much of a change of getting around that, at least not until we see some plug-in support in Gerrit :/
Actually it is configured here:... but it is broken since Dec 21st :-((probably the GIT URL needs to be updated again and pointing now to Gerrit)
I would be nice to have the Gerrit trigger plug-in as well, in order to have the feedback on Gerrit about the status of the builded change-set.
A fair chunk of it is, yes. It will require some refactoring to move
this around.
> @Shawn: do you have any concern in moving those commands to a JSON-RPC level
> ? (and thus exposed via HTTP/S)
review should be moved to a JSON-RPC interface, yes. We may need to be
careful with gwtjsonrpc's extension of the JSON-RPC 2.0 specification
where it embeds the xsrfToken in the request body. This is
non-standard, so makes it harder for a JSON-RPC client to use the
interface. User authentication is also difficult with JSON-RPC because
we don't have a good standard like the public/private SSH key to rely
on. Aside from that, it should be simple to define the review command
arguments as a structure, make a JSON-RPC interface to parse that
structure and feed it to a common Review implementation, and have the
SSH Review class convert its arguments into the same structure and
feed it to the same implementation class that the JSON-RPC code uses.
stream-events is more difficult. It should also be available as a
JSON-RPC interface. But its way more complex. Just to give you an
idea, gerrit-review is actually a group of machines, in geographically
diverse regions. An event processed in a server in the EU isn't
available to the other servers. In order to do stream-events all
events need to be aggregated and then redistributed. Until that is
done, stream-events on gerrit-review.googlesource.com isn't going to
be useful. stream-events could be done as a JSON-RPC request to supply
the parameters to configure what the stream receives, but then it
needs to really be a stream of JSON just like the SSH command does, so
its not quite JSON-RPC. The HTTP stream will be broken every so often,
and need to be setup again by the client. Which means the stream needs
to be able to resume from where the client last left off. We discussed
this at GitTogether as being necessary for the SSH version too, but I
think its even more critical with the HTTP interface.
So yes, we should expose these by HTTP. And it would be great if
someone could do some (or all!) of the work. :-)
I don't know what you are talking about. We have history going back to
Oct 21, 2008:
https://gerrit-review.googlesource.com/#/q/status:merged,n,00007ae200000318
Any history predating the launch of the Android Open Source Project
doesn't exist anymore. Nor is it relevant. Gerrit this old is Python
running on Google AppEngine. You really don't want to look at that.
I don't know what you are talking about. We have history going back to
Oct 21, 2008:
https://gerrit-review.googlesource.com/#/q/status:merged,n,00007ae200000318
You may need to edit your profile information with Google Accounts,
try this link:
https://www.google.com/accounts/EditUserInfo
After changes are made there, you need to trigger login with Gerrit to
import the updated name:
https://gerrit-review.googlesource.com/login/
We run Gerrit Code Review in a mode similar to LDAP, where the Google
Account system provides the name and primary email address for each
account.
Neither. :-(
We don't run as a normal web application. So we don't use the Daemon
(used by gerrit.sh start) or the WebAppInjector (used by Gerrit in a
standard WAR deployment scheme) classes. Instead we build up the
application ourselves by creating new Guice injectors that mirror what
the Daemon class does, only using Google Servlet Engine instead of
Jetty. FWIW, I would never use Google Servlet Engine in the real
Gerrit build. Jetty is a much cleaner HTTP server to work with. Google
Servlet Engine is however required in order to run in our data
centers, so I had to hack Gerrit to run within it. I vastly prefer
debugging/working with Jetty. :-)
Because we are setting up our own custom injection environment, we
rebind some implementations of interfaces in the Gerrit application to
different backends. So Realm is bound to GoogleAccountRealm, which it
turns out is entirely a no-op class for us, because we aren't fully
integrated with Google Accounts. We don't for example integrate with
Google Groups so there are no group membership lookups to perform in
the Realm implementation. In order to do group integration, I have to
rethink the Realm API. We cannot ask the Google Account system for all
groups you are a member of, this could be a huge set (e.g. 3000) if
you joined a lot of mailing lists, and only maybe 2 will apply to this
Gerrit environment. LDAP directories have this exact same problem, it
is not uncommon for companies to have users in a large number of
groups to reflect company email distributions, project teams, access
controls, etc. So either way we really need to refactor the Realm API
to better support large directories.
We also bind our own WebSession implementation, and our own
GoogleAccountPostLoginServlet for /login/*. Combined with Google
proprietary filters to manage cookie state, we get single sign-on with
Google Accounts.
Since SSH is not available, we omit most of the SSH stuff from the
Guice environment.
So we have a huge duplicate of Daemon in our environment that sets up
our Google Servlet Engine, our integration with Google Accounts, and
our custom database backend (which is Google Megastore sitting on top
of Google Bigtable, similar to Google AppEngine but not).
It would be much nicer if we had real pluggable authentication. But we
don't, yet. Its on my list of things that we should do as a project.
Using Guice injection to manage it is probably the right short term
approach. We have some of that using the Realm interface and its
various implementations that are already present, but the way this is
done is incredibly messy and difficult to follow. Long term we may
find another way to do plugins other than Guice injection, but for
something so key to a server like authentication its unlikely to need
to change at runtime so it isn't very important for authentication to
be hot swappable. :-)
The name is imported from the Google Account.
You need to edit your profile information with Google Accounts,
The username is always empty. We don't populate it because the
username is actually just "git" for everyone.
> Besides, my user account is not getting added to a group.
What group do you think your user account should be added to? If you
are talking about the NVIDIA Contributors group, you would need to ask
the owners of it to add your account.
According to [1] in the documentation the URL would be:
https://gerrit-review.googlesource.com/tools/hooks/commit-msg
[1] http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.2/user-changeid.html#_creation