Hi Antony,
Sorry for the delay. Your e-mail got buried in my inbox a bit. Let me see
if I can help answer your questions.
1) The documentation for this is indeed light. I'm working on a whole new
set of detailed guides for configuring repositories.
1a) It's generally not the preferred way, if there are alternatives, but I
think for Gitolite currently, it's maybe required. Basically, we prefer to
talk to the repository through some API, but Gitolite, last I checked,
didn't have one we could use that met our needs. Looking at the docs now, I
think that's perhaps the case.
The downside to the pull method is that you run the risk of someone pushing
and then immediately basing a review request off the pushed change, and
hitting "File not found" errors.
If Gitolite allows you to view the raw contents of a file, given a path and
blob SHA, either without requiring authentication or working with Basic
HTTP Auth, then you can configure the repository to use the Raw File URL
mask field, as per the docs, to point to a version of that path. That would
contain some markers ("" and "") that would get filled
in when Review Board wants to access a given file. This is the preferred
way, for Git hosting solutions that we don't or can't have direct support
for.
1b) If you can use the raw file mask method, you don't need a local clone
at all.
1c) You'd need an SSH key if working with a remote Git repository, in order
to verify repository information and such. If it's a local clone, it's not
needed. Primarily, SSH keys are used for other services, like Subversion,
where you can have more detailed communication with the service over SSH.
Git's remote access protocol, unfortunately, is pretty limited, and we
can't do the kinds of things we need with it, hence the local clone or raw
file URL methods.
I'm not sure what would make it slow.. Fetching should be fast enough, and
shouldn't impact Review Board that much. Assuming you have a working
memcached server, Review Board will only need to fetch files once, and then
they're cached for a good long while.
2) The key is indeed generated by rb-site. You definitely should keep it.
We use Chef for our deployments, and do not run rb-site to create a site on
deployment. Instead, we took the settings_local.py on our server and turned
it into a template that Chef installed (storing some data like the database
info and secret key as variables in encrypted data bags), which then are
used with the template to create the final settings_local.py file).
There's a fair amount of state dependent on that secret key, so keep it
secret and safe, but don't replace it unless absolutely necessary.
Hope that helps! Happy to clarify any of this further.
And thanks about the mobile CSS :) We have a ways to go, but I hope it's
been useful so far!
Christian
--
Christian Hammond - christ...@beanbaginc.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com
On Thu, Feb 11, 2016 at 1:50 PM, Antony Gelberg
wrote:
> Hi all,
>
> So I'm upgrading our ancient, unmaintained "who knows how this even
> worked" 1.7.20 to 2.5.2. It's going well, but I have a couple of questions.
>
> 1) We have our own git server, running gitolite. I have read the docs but
> I found them a bit lightweight on the subject:
> a) There's a crontab running every minute, doing a git fetch -q. Is this
> considered "normal" for a RB / git install?
> b) In the repository settings, the Path is set to the local clone path,
> and the Mirror Path is set to gitoli...@git.server.name:reponame. Do we
> have to have a local clone? (I think the answer here is yes, from the docs,
> but just want to check...)
> c) We have an SSH key configured in the RB settings. I don't see the
> point of the SSH key, if a crontab is already updating the local git
> clone...
> I ask because the server is occasionally slow to respond, but top and the
> logs show nothing interesting going on (that I've noticed). I'm wondering
> if doing a git fetch every minute is somehow making it hang, although I
> don't see git in top at that time either, so I'm kind of clutching at
> straws. I'm happy for any advice on how things *should* be configured, this
> is a good time to change the config.
>
> 2) I see that the config file contains a random secret that I assume was
> generated by rb-site install. I'd like to know if changing that will break
> anything. The reason behind it is that I want to Puppetize the server
> install, and I'd rather generate the config file with rb-site install, than
> store it in S3 and copy it into place. Any tips on this would be really
> welcome.
>
> The mobile CSS looks just great, by the way. :)
>
> Please let me know if I haven't been clear above, happy to provide more
> information as necessary.
>
> --
> Supercharge your Review Board with Power Pack:
> https://www.reviewboard.org/powerpack/
> Want us to host Review Board for you? Check out RBCommons:
> https://rbcommons.com/
