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

[Mauricio Lima Pilla <pilla@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5753 bytes --]

Perspective of a Gitlab user:

We use it for managing a small research lab. First I had it installed in a
Ubuntu server, but recently -- an year ago -- I moved it to a Docker
container.

It seems to be very important to keep it up-to-date or at least go through
intermediate versions to avoid breakages. That said, it seems to work
pretty well even with the LDAP integration on. Even when I managed to break
it in a upgrade, it was fairly easy to get it running again. If you are
smarter than me, you would first make a snapshot of the container though.

Shame on me for not keeping those more up-to-date with their releases.




On Thu, Jun 14, 2018 at 11:15 AM Alec Warner <antarus@gentoo.org> wrote:

>
>
> On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot <chewi@gentoo.org> wrote:
>
>> 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.
>>
>>
> 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
>>
>>
>

-- 
Mauricio Lima Pilla, D.Sc.
http://beagle.ufpel.edu.br/~pilla

pilla@ufpel.edu.br, mauricio.pilla@gmail.com, pilla@gentoo.org

"I'm just very selective about the reality I choose to accept."
                                                              -- Calvin

[-- Attachment #2: Type: text/html, Size: 7629 bytes --]