Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Alec Warner]

On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot <chewi@g.o> wrote:

> On Mon, 11 Jun 2018 09:28:37 -0400
> Rich Freeman <rich0@g.o> 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.
>
>
They seem to offer docker packages, so we could just nab those and run them
in containers on hosts. I'm not too keen on doing a bunch of (really what I
consider busywork) to try to 'get it working on Gentoo.' We already use
upstream provided containers and I expect that to continue as upstreams
continue to abandon the 'release packages' model and move to 'release sets
of containers' model.

-A


> I hope you found this informative!
>
> Regards,
> --
> James Le Cuirot (chewi)
> Gentoo Linux Developer
>
>