4 ms·

I'd love for you to explain your motives behind not using Omnibus further. Nowadays we provide images / containers for most major platforms, so there should de

I'd love for you to explain your motives behind not using Omnibus further. Nowadays we provide images / containers for most major platforms, so there should definitely be a good solution for you there. That said, we make the Omnibus packages as that's the easiest and best way to maintain GitLab. It takes all the work away from you. The vast majority of our customers use Omnibus, even secure instances with thousands of developers.

zebra9978 10y ago
quick question - did you consider using jruby ? I see on your docs you mention that you use certain libs with native extensions... but 20 mil should go a long way towards resolving those. how about building out a single jar based deployment based on jruby ? For example, mingle is built on jruby (ruby on rails) and packaged as a easy to install jar file [1] [1] https://www.thoughtworks.com/mingle/news/2015/02/18/Forty-Min-Build.html https://www.thoughtworks.com/mingle/news/2015/02/18/Forty-Mi... jruby will be higher performing and will use overall lesser memory in general (yes.. the jvm takes up quite a bit of RAM during startup). Running a jar in production using jetty is a breeze.
__david__ 10y ago
Not OP, but I dislike many things about your omnibus packages. I hate packages that install into /opt (thanks for the extra tld). I hate that it's 900+MB of completely redundant junk—nginx? check, postgres, check, and entire ruby? git? curl? All of those are on my system already. That said, I switched to it after maintaining a hand installed version and I love how I don't have to run rails schema upgrades by hand any more. I used to put off upgrading gitlab for months because it was such a pain and now I don't have to think about it at all. Rails devs could learn a lot from php devs in that regard (upgrading wordpress is absolutely trivial to upgrading gitlab). So yeah, I love the omnibus package since it means I don't have to think about it any more; I hate the omnibus package because it's a huge redundant monolith and pure crap from the point of view of a Debian package purist.
- Rondom 10y ago
  Debian stretch will have a native GitLab package. https://packages.debian.org/stretch/gitlab https://packages.debian.org/stretch/gitlab Whether there are enough volunteers to keep it and its dependencies up to date using backports remains to be seen, though.
- snuxoll 10y ago
  This is a nuisance for me as a CentOS admin as well. I absolutely dislike software that decides to just plop a big bag of crap in /opt. I don't want something administering it's own PostgreSQL or nginx instance, let those choices and the administration of these services up to system administrators and alternatively provide a quick setup tool for the less inclined. I work in a mostly .Net shop, but the couple Python+Flask apps I maintain and administer integrate with everything else the way I expect as a sysadmin. As a Linux guy I have scoffed at Windows shops for ages for the sin of "xcopy deploy" but omnibus packages are no better.

zebra9978 10y ago

quick question - did you consider using jruby ? I see on your docs you mention that you use certain libs with native extensions... but 20 mil should go a long way towards resolving those. how about building out a single jar based deployment based on jruby ? For example, mingle is built on jruby (ruby on rails) and packaged as a easy to install jar file [1] [1] https://www.thoughtworks.com/mingle/news/2015/02/18/Forty-Min-Build.html https://www.thoughtworks.com/mingle/news/2015/02/18/Forty-Mi... jruby will be higher performing and will use overall lesser memory in general (yes.. the jvm takes up quite a bit of RAM during startup). Running a jar in production using jetty is a breeze.

__david__ 10y ago

Not OP, but I dislike many things about your omnibus packages. I hate packages that install into /opt (thanks for the extra tld). I hate that it's 900+MB of completely redundant junk—nginx? check, postgres, check, and entire ruby? git? curl? All of those are on my system already. That said, I switched to it after maintaining a hand installed version and I love how I don't have to run rails schema upgrades by hand any more. I used to put off upgrading gitlab for months because it was such a pain and now I don't have to think about it at all. Rails devs could learn a lot from php devs in that regard (upgrading wordpress is absolutely trivial to upgrading gitlab). So yeah, I love the omnibus package since it means I don't have to think about it any more; I hate the omnibus package because it's a huge redundant monolith and pure crap from the point of view of a Debian package purist.

Rondom 10y ago
Debian stretch will have a native GitLab package. https://packages.debian.org/stretch/gitlab https://packages.debian.org/stretch/gitlab Whether there are enough volunteers to keep it and its dependencies up to date using backports remains to be seen, though.
snuxoll 10y ago
This is a nuisance for me as a CentOS admin as well. I absolutely dislike software that decides to just plop a big bag of crap in /opt. I don't want something administering it's own PostgreSQL or nginx instance, let those choices and the administration of these services up to system administrators and alternatively provide a quick setup tool for the less inclined. I work in a mostly .Net shop, but the couple Python+Flask apps I maintain and administer integrate with everything else the way I expect as a sysadmin. As a Linux guy I have scoffed at Windows shops for ages for the sin of "xcopy deploy" but omnibus packages are no better.