| 1 |
On Mon, 11 Jun 2018 09:28:37 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> All that said, I haven't used the gitlab core functionality |
| 5 |
> personally, so I can't vouch for how it stands up on its own against |
| 6 |
> github. I might go deploy it in a container or something to try it |
| 7 |
> out. |
| 8 |
|
| 9 |
I used our own self-hosted instance at work. I think it is perfectly |
| 10 |
adequate. I haven't dug in but it seems to have quite a rich API so |
| 11 |
there's lots of potential. |
| 12 |
|
| 13 |
> My understanding is that the main barrier to having Gentoo infra host |
| 14 |
> gitlab is ruby - they don't like ruby (I don't know all the reasons - |
| 15 |
> they're probably good ones). If github.com is offering free hosting |
| 16 |
> that would be a way to get out of that problem. On the other hand, if |
| 17 |
> something bad does happen down the road, there is always the chance |
| 18 |
> that we'll have to move to self-hosting without a lot of warning, and |
| 19 |
> that means having to deal with ruby whether we like it or not (or lose |
| 20 |
> stuff like issues/PRs/etc that aren't in git itself). |
| 21 |
|
| 22 |
There are more than two options available here. |
| 23 |
|
| 24 |
There are various cloud options including Docker, Kubernetes, and |
| 25 |
OpenShift. I don't know much about that. |
| 26 |
|
| 27 |
GitLab's preferred method of installation is their Omnibus packages for |
| 28 |
various distributions but obviously not Gentoo. This is basically |
| 29 |
uber-bundling where they bundle just about everything including |
| 30 |
PostgreSQL. I have not tried this method. I don't know how feasible or |
| 31 |
even desirable it would be to try and use these. |
| 32 |
|
| 33 |
There is a Chef cookbook for installing the Omnibus packages but this |
| 34 |
is limited to the same set of distributions. |
| 35 |
|
| 36 |
There is also an unofficial Chef cookbook for installing "from source" |
| 37 |
that I currently maintain, somewhat minimally. Unfortunately it only |
| 38 |
supports RHEL (and derivatives) and Debian, and I only test on CentOS. |
| 39 |
Their own documentation for installing from source is fairly |
| 40 |
comprehensive but the cookbook gives a good indication of how you can |
| 41 |
script it up. |
| 42 |
|
| 43 |
https://github.com/atomic-penguin/cookbook-gitlab-deprecated |
| 44 |
|
| 45 |
When we say "from source", what we actually mean is that the various |
| 46 |
dependencies, apart from the Ruby gems and JavaScript libraries, are |
| 47 |
installed from distro packages where possible or from source when the |
| 48 |
packages are too old. This includes Ruby itself, Go, NodeJS, |
| 49 |
PostgreSQL, Redis, nginx, and obviously git. I expect Gentoo would have |
| 50 |
no trouble providing recent enough versions of these. You then clone |
| 51 |
the various GitLab repositories (currently 4, could be worse), build |
| 52 |
the Go code, and install further dependencies with Bundler and YARD, |
| 53 |
before doing some final setup tasks and firing it up. |
| 54 |
|
| 55 |
Using Bundler and YARD goes against Gentoo packaging but the list of |
| 56 |
dependencies for both sides is extremely long. I very much doubt we |
| 57 |
could keep on top of that and I understand this kind of pain because |
| 58 |
this is the same situation that the Java team finds itself in. At least |
| 59 |
in this case, there are most likely no pre-compiled binaries involved |
| 60 |
so the benefits of packaging are limited anyway. Ruby gems that include |
| 61 |
native code typically build from source on installation. |
| 62 |
|
| 63 |
I can't comment much about the JavaScript side but on the Ruby side, |
| 64 |
there are Gemfile.lock files present that lock the Ruby gem |
| 65 |
dependencies down to specific versions. If we did want to package the |
| 66 |
gems, we would probably not want to be tied to such specific versions. |
| 67 |
You could possibly delete these and fall back to the looser constraints |
| 68 |
in the Gemfiles but you may run into unexpected issues. You could argue |
| 69 |
that we may want to do this even if we don't package the gems in order |
| 70 |
to benefit from fixes (including security) but GitLab is very actively |
| 71 |
maintained and the lock files are frequently updated. |
| 72 |
|
| 73 |
Keep in mind that GitLab is a very fast-moving project. Security issues |
| 74 |
are frequently found but these are fixed quickly. This is not the sort |
| 75 |
of project we could install once and then maybe patch up just once a |
| 76 |
year or so. |
| 77 |
|
| 78 |
I hope you found this informative! |
| 79 |
|
| 80 |
Regards, |
| 81 |
-- |
| 82 |
James Le Cuirot (chewi) |
| 83 |
Gentoo Linux Developer |
Archives