On Mon, 11 Jun 2018 09:28:37 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> All that said, I haven't used the gitlab core functionality
> personally, so I can't vouch for how it stands up on its own against
> github.  I might go deploy it in a container or something to try it
> out.

I used our own self-hosted instance at work. I think it is perfectly
adequate. I haven't dug in but it seems to have quite a rich API so
there's lots of potential.

> My understanding is that the main barrier to having Gentoo infra host
> gitlab is ruby - they don't like ruby (I don't know all the reasons -
> they're probably good ones).  If github.com is offering free hosting
> that would be a way to get out of that problem.  On the other hand, if
> something bad does happen down the road, there is always the chance
> that we'll have to move to self-hosting without a lot of warning, and
> that means having to deal with ruby whether we like it or not (or lose
> stuff like issues/PRs/etc that aren't in git itself).

There are more than two options available here.

There are various cloud options including Docker, Kubernetes, and
OpenShift. I don't know much about that.

GitLab's preferred method of installation is their Omnibus packages for
various distributions but obviously not Gentoo. This is basically
uber-bundling where they bundle just about everything including
PostgreSQL. I have not tried this method. I don't know how feasible or
even desirable it would be to try and use these.

There is a Chef cookbook for installing the Omnibus packages but this
is limited to the same set of distributions.

There is also an unofficial Chef cookbook for installing "from source"
that I currently maintain, somewhat minimally. Unfortunately it only
supports RHEL (and derivatives) and Debian, and I only test on CentOS.
Their own documentation for installing from source is fairly
comprehensive but the cookbook gives a good indication of how you can
script it up.

https://github.com/atomic-penguin/cookbook-gitlab-deprecated

When we say "from source", what we actually mean is that the various
dependencies, apart from the Ruby gems and JavaScript libraries, are
installed from distro packages where possible or from source when the
packages are too old. This includes Ruby itself, Go, NodeJS,
PostgreSQL, Redis, nginx, and obviously git. I expect Gentoo would have
no trouble providing recent enough versions of these. You then clone
the various GitLab repositories (currently 4, could be worse), build
the Go code, and install further dependencies with Bundler and YARD,
before doing some final setup tasks and firing it up.

Using Bundler and YARD goes against Gentoo packaging but the list of
dependencies for both sides is extremely long. I very much doubt we
could keep on top of that and I understand this kind of pain because
this is the same situation that the Java team finds itself in. At least
in this case, there are most likely no pre-compiled binaries involved
so the benefits of packaging are limited anyway. Ruby gems that include
native code typically build from source on installation.

I can't comment much about the JavaScript side but on the Ruby side,
there are Gemfile.lock files present that lock the Ruby gem
dependencies down to specific versions. If we did want to package the
gems, we would probably not want to be tied to such specific versions.
You could possibly delete these and fall back to the looser constraints
in the Gemfiles but you may run into unexpected issues. You could argue
that we may want to do this even if we don't package the gems in order
to benefit from fixes (including security) but GitLab is very actively
maintained and the lock files are frequently updated.

Keep in mind that GitLab is a very fast-moving project. Security issues
are frequently found but these are fixed quickly. This is not the sort
of project we could install once and then maybe patch up just once a
year or so.

I hope you found this informative!

Regards,
--
James Le Cuirot (chewi)
Gentoo Linux Developer