1 |
Perspective of a Gitlab user: |
2 |
|
3 |
We use it for managing a small research lab. First I had it installed in a |
4 |
Ubuntu server, but recently -- an year ago -- I moved it to a Docker |
5 |
container. |
6 |
|
7 |
It seems to be very important to keep it up-to-date or at least go through |
8 |
intermediate versions to avoid breakages. That said, it seems to work |
9 |
pretty well even with the LDAP integration on. Even when I managed to break |
10 |
it in a upgrade, it was fairly easy to get it running again. If you are |
11 |
smarter than me, you would first make a snapshot of the container though. |
12 |
|
13 |
Shame on me for not keeping those more up-to-date with their releases. |
14 |
|
15 |
|
16 |
|
17 |
|
18 |
On Thu, Jun 14, 2018 at 11:15 AM Alec Warner <antarus@g.o> wrote: |
19 |
|
20 |
> |
21 |
> |
22 |
> On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot <chewi@g.o> wrote: |
23 |
> |
24 |
>> On Mon, 11 Jun 2018 09:28:37 -0400 |
25 |
>> Rich Freeman <rich0@g.o> wrote: |
26 |
>> |
27 |
>> > All that said, I haven't used the gitlab core functionality |
28 |
>> > personally, so I can't vouch for how it stands up on its own against |
29 |
>> > github. I might go deploy it in a container or something to try it |
30 |
>> > out. |
31 |
>> |
32 |
>> I used our own self-hosted instance at work. I think it is perfectly |
33 |
>> adequate. I haven't dug in but it seems to have quite a rich API so |
34 |
>> there's lots of potential. |
35 |
>> |
36 |
>> > My understanding is that the main barrier to having Gentoo infra host |
37 |
>> > gitlab is ruby - they don't like ruby (I don't know all the reasons - |
38 |
>> > they're probably good ones). If github.com is offering free hosting |
39 |
>> > that would be a way to get out of that problem. On the other hand, if |
40 |
>> > something bad does happen down the road, there is always the chance |
41 |
>> > that we'll have to move to self-hosting without a lot of warning, and |
42 |
>> > that means having to deal with ruby whether we like it or not (or lose |
43 |
>> > stuff like issues/PRs/etc that aren't in git itself). |
44 |
>> |
45 |
>> There are more than two options available here. |
46 |
>> |
47 |
>> There are various cloud options including Docker, Kubernetes, and |
48 |
>> OpenShift. I don't know much about that. |
49 |
>> |
50 |
>> GitLab's preferred method of installation is their Omnibus packages for |
51 |
>> various distributions but obviously not Gentoo. This is basically |
52 |
>> uber-bundling where they bundle just about everything including |
53 |
>> PostgreSQL. I have not tried this method. I don't know how feasible or |
54 |
>> even desirable it would be to try and use these. |
55 |
>> |
56 |
>> There is a Chef cookbook for installing the Omnibus packages but this |
57 |
>> is limited to the same set of distributions. |
58 |
>> |
59 |
>> There is also an unofficial Chef cookbook for installing "from source" |
60 |
>> that I currently maintain, somewhat minimally. Unfortunately it only |
61 |
>> supports RHEL (and derivatives) and Debian, and I only test on CentOS. |
62 |
>> Their own documentation for installing from source is fairly |
63 |
>> comprehensive but the cookbook gives a good indication of how you can |
64 |
>> script it up. |
65 |
>> |
66 |
>> https://github.com/atomic-penguin/cookbook-gitlab-deprecated |
67 |
>> |
68 |
>> When we say "from source", what we actually mean is that the various |
69 |
>> dependencies, apart from the Ruby gems and JavaScript libraries, are |
70 |
>> installed from distro packages where possible or from source when the |
71 |
>> packages are too old. This includes Ruby itself, Go, NodeJS, |
72 |
>> PostgreSQL, Redis, nginx, and obviously git. I expect Gentoo would have |
73 |
>> no trouble providing recent enough versions of these. You then clone |
74 |
>> the various GitLab repositories (currently 4, could be worse), build |
75 |
>> the Go code, and install further dependencies with Bundler and YARD, |
76 |
>> before doing some final setup tasks and firing it up. |
77 |
>> |
78 |
>> Using Bundler and YARD goes against Gentoo packaging but the list of |
79 |
>> dependencies for both sides is extremely long. I very much doubt we |
80 |
>> could keep on top of that and I understand this kind of pain because |
81 |
>> this is the same situation that the Java team finds itself in. At least |
82 |
>> in this case, there are most likely no pre-compiled binaries involved |
83 |
>> so the benefits of packaging are limited anyway. Ruby gems that include |
84 |
>> native code typically build from source on installation. |
85 |
>> |
86 |
>> I can't comment much about the JavaScript side but on the Ruby side, |
87 |
>> there are Gemfile.lock files present that lock the Ruby gem |
88 |
>> dependencies down to specific versions. If we did want to package the |
89 |
>> gems, we would probably not want to be tied to such specific versions. |
90 |
>> You could possibly delete these and fall back to the looser constraints |
91 |
>> in the Gemfiles but you may run into unexpected issues. You could argue |
92 |
>> that we may want to do this even if we don't package the gems in order |
93 |
>> to benefit from fixes (including security) but GitLab is very actively |
94 |
>> maintained and the lock files are frequently updated. |
95 |
>> |
96 |
>> Keep in mind that GitLab is a very fast-moving project. Security issues |
97 |
>> are frequently found but these are fixed quickly. This is not the sort |
98 |
>> of project we could install once and then maybe patch up just once a |
99 |
>> year or so. |
100 |
>> |
101 |
>> |
102 |
> They seem to offer docker packages, so we could just nab those and run |
103 |
> them in containers on hosts. I'm not too keen on doing a bunch of (really |
104 |
> what I consider busywork) to try to 'get it working on Gentoo.' We already |
105 |
> use upstream provided containers and I expect that to continue as upstreams |
106 |
> continue to abandon the 'release packages' model and move to 'release sets |
107 |
> of containers' model. |
108 |
> |
109 |
> -A |
110 |
> |
111 |
> |
112 |
>> I hope you found this informative! |
113 |
>> |
114 |
>> Regards, |
115 |
>> -- |
116 |
>> James Le Cuirot (chewi) |
117 |
>> Gentoo Linux Developer |
118 |
>> |
119 |
>> |
120 |
> |
121 |
|
122 |
-- |
123 |
Mauricio Lima Pilla, D.Sc. |
124 |
http://beagle.ufpel.edu.br/~pilla |
125 |
|
126 |
pilla@×××××××××.br, mauricio.pilla@×××××.com, pilla@g.o |
127 |
|
128 |
"I'm just very selective about the reality I choose to accept." |
129 |
-- Calvin |