gerrit version

40 views
Skip to first unread message

Ishaaq Chandy

unread,
May 10, 2010, 11:38:55 PM5/10/10
to Repo and Gerrit Discussion
Hi guys,
I was trying to use the "gerrit create-account" command to create an
account for my build server however that gave a "not found" error. I
am using v2.1.2.4. So then I checked and noticed that the version of
gerrit you self-host does indeed have that command. At the footer at
https://review.source.android.com I notice a different version:
2.1.2.4-43-g3c55dde

I searched for that version string in the branches, SHAs, logs and
tags in my clone of the gerrit repo and couldn't find it. So my
question is: how do you guys choose a version to deploy to
review.source.android.com? I figure if I use the version you trust
enough to self-host I should be relatively safe.

Thanks
Ishaaq

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

Shawn Pearce

unread,
May 11, 2010, 12:20:29 PM5/11/10
to Ishaaq Chandy, Repo and Gerrit Discussion
On Mon, May 10, 2010 at 20:38, Ishaaq Chandy <ish...@gmail.com> wrote:
> I was trying to use the "gerrit create-account" command to create an
> account for my build server however that gave a "not found" error. I
> am using v2.1.2.4. So then I checked and noticed that the version of
> gerrit you self-host does indeed have that command. At the footer at
> https://review.source.android.com I notice a different version:
> 2.1.2.4-43-g3c55dde
>
> I searched for that version string in the branches, SHAs, logs and
> tags in my clone of the gerrit repo and couldn't find it.

Its the commit SHA-1 3c55dde. The version string you are seeing is
the output of git describe when run on that commit. Its showing the
last known tag, then the number of commits since that tag was made,
and finally the abbreviated commit SHA-1.

> So my
> question is: how do you guys choose a version to deploy to
> review.source.android.com? I figure if I use the version you trust
> enough to self-host I should be relatively safe.

I use a version that I've reasonably tested locally and felt safe
enough to deploy. But its often known to be incomplete, since its
still in development. I don't deploy versions which are horribly
broken, or which will fail to function correctly for the average user.
But sometimes I deploy versions that have bugs that an Administrator
might have to work around.

Ishaaq Chandy

unread,
May 11, 2010, 12:36:24 PM5/11/10
to Shawn Pearce, Repo and Gerrit Discussion
Thanks Shawn,

So, I guess that brings up the next question: does that particular
version have any bugs you know of that an Administrator (i.e. me!)
would have to work around? :)

Thanks,
Ishaaq

Shawn Pearce

unread,
May 11, 2010, 12:57:45 PM5/11/10
to Ishaaq Chandy, Repo and Gerrit Discussion

Replication doesn't honor ref level access control and sometimes the ref level access controls behave in surprising ways by removing inherited access rules that you wanted to apply to a ref.  In the former case ref level read access is a new feature, but its already fixed in a newer commit on the master branch.  In the latter case you can work around it by repeating the access rules in the project itself on the ref you need them on.

Reply all
Reply to author
Forward
0 new messages