Add OpenSUSE and SLE to Gitlab Development Kit
I have managed to get Gitlab Development Kit to work on openSUSE leap 42.1, probably I'm not the first person to do so as I see OpenSUSE packages have been built in various places, but since nobody put that into the Gitlab readmes per-linux-distro markdown yet, this issue is an offer to make a PR for that.
First I will summarize how I got it working, in case anyone has any suggestions on doing this differently, that I should include in my readme-PR.
These instructions should work on OpenSUSE LEAP 42.1, and should almost work on OpenSUSE Tumbleweed except that I had some gem native extension build problems with libicu.
The instructions are similar to RedHat instructions but SUSE-family uses zypper
instead of dnf
or yum
.
Packages to remove and disable (Tumbleweed only)
uninstall opensuse phantomjs package if it was installed, uninstall it with zypper uninstall phantomjs
below we will install one with npm.
Install required suse packages prerequisites, including nodejs, postgres, redis, and various libraries with their headers required later by gems.
zypper install libxslt-devel postgresql postgresql-devel libpqxx-devel redis libicu-devel nodejs git ed cmake \
rpm-build gcc-c++ krb5-devel go postgresql-server postgresql-contrib \
libxml2-devel libxml2-devel-32bit
If you haven't got RVM and ruby yet
I'm including this section because of the annoyance that the author of RVM requires your bash shell to be a login shell or rvm use won't work. This means that in addition to the instructions on the RVM website you have to modify your desktop (in my case KDE Plasma's Konsole) to run /usr/bin/bash -l
, that is, add the -l
parameter. I find this kind of contrary-larry status (Konsole author is opinionated, bash should not be a login shell, RVM author is opinionated, bash has to be a login shell or you can't use RVM from your X Konsole) to be user-hostile to new users and should be called out in the readme to help new users out.
# get rvm (if gpg fails first time, just try it again)
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
-or-
command curl -sSL https://rvm.io/mpapis.asc | gpg2 --import -
\curl -sSL https://get.rvm.io | bash -s stable
# make it so rvm is in your path, either log into a fresh shell or do this:
source ~/.rvm/scripts/rvm
Now that rvm is on my machine, I should make sure I am running my bash process with -l
option. In Konsole (kde plasma desktop), I click Settings -> Edit Current Profile, go to General tab and see if Command is /bin/bash
, change it to /bin/bash -l
. Now I start a new Konsole window, and continue using rvm, which has decided that each of my shells must (if it wants to use ruby) be a separate login shell:
# use rvm to install ruby
rvm --version
rvm install 2.3.1
rvm use 2.3.1
ruby --version
gem install bundler
Make it more likely that GDK rails gem installs will succeed, make sure complex GEMS install before using GDK install
During the installation of the nokogiri
gem which is required by rails, it tries to build a lot of bundled dependencies because the authors of the gem believe that operating system vendors are too slow to release patches. This has resulted in a complex set of C library headers and code being bundled with the gem, and these are not actually completely standalone, as these libraries can have dependencies on other things that are on your system.
To find out if you're going to have problems, try just this:
gem install nokogiri
I thought this might help, but it doesn't help:
gem install nokogiri -- --use-system-libraries
Instead, I needed this command sequence to restart after gdk install
failed at the gem install nokogiri stage:
bundle config build.nokogiri "--use-system-libraries"
gdk reconfigure
If that succeeds, good, you may continue, and if not, you should try to figure out what to install (zypper install something-devel
) to fix the problem with nokogiri. A log file is created that has to be inspected to find what headers (.h) or libraries (.a) are missing.
IPTABLES/Firewall?
Now is a good time to add iptables exceptions, or use YaST Firewall module to unblock ports 3000, and any others required by Gitlab Development Kit. A nice list of those would be a good idea to put into the gdk.
PhantomJS Manual Installation (Optional/Tumbleweed)
Normal phantomjs install:
npm install -g phantomjs
If for some reason the phantomjs installed by npm install -g phantomjs
does not work, it's possible to fetch it manually like this. This workaround only seems necessary on Tumbleweed right now, but because these things could break in the future, this workaround might be worth documenting.
# after ruby rvm has modified ~/.profile, you can install phantomjs
PHANTOM_JS="phantomjs-2.1.1-linux-x86_64"
cd ~
wget https://bitbucket.org/ariya/phantomjs/downloads/$PHANTOM_JS.tar.bz2
tar -xvjf $PHANTOM_JS.tar.bz2
sudo mv $PHANTOM_JS /usr/local/share
sudo ln -s /usr/local/share/$PHANTOM_JS/bin/phantomjs /usr/local/bin
# now add /usr/local/bin to PATH in ~/.profile, in your editor modify the export PATH line to be:
# export PATH="$PATH:$HOME/.rvm/bin:/usr/local/bin" # RVM and PHANTOMJS
source ~/.profile
phantomjs --version
Stop Suse's main POSTGRES instance if it's in the way
Gitlab Development kit has its own postgres-startup logic inside the gdk kit but if you feel that the opensuse postgres instance might be getting in the way, you can stop it with:
sudo systemctl stop postgresql
Manual Steps for using OpenSUSE's REDIS with GDK
OpenSuse LEAP does not enable redis in systemd automatically, which is actually a well thought out choice, so you have to enable the default instance manually and then start it, using systemctl to enable the service and start it.
sudo systemctl enable redis@default
sudo systemctl start redis@default
Also it should be noted that the GDK does not check if redis-server
is in your path, and it will die with other errors, like "could not connect to postgres".
OpenSuse LEAP puts redis-server in /usr/sbin, which is not where a developers using gdk would want it, and I don't think a non-root account should add the /usr/sbin directory to their path, as there is stuff in there that I definitely don't want in my non-root-path. So I did this:
sudo ln -s /usr/sbin/redis-server /home/wpostma/bin/redis-server
If that did the trick, running which redis-server
should confirm that redis-server is visible in your path, otherwise go make ~/bin
, and add it to your bash profile or wherever you keep your export PATH=...
stuff.
Now ready for the GDK init/install
This is the end of the normal instructions. You're ready to decide where your workspace will be, go to that folder, and run gdk init
and then cd gitlab-development-kit
and then gdk install
. That might die with an error if any of the 300+ gems won't install on your machine. In that case, you might need more libraries and headers.
If I could suggest an improvement it is that gdk init
should either WARN and pause, or just stop immediately if redis-server
, or go
or postgres
or any of a number of things which ought to be in the path and are not found by the which
utility.
Workaround : bundle config steps
After the first time the gdk clones your gitlab sources, if bundler fails to install nokogiri
or charlock_holmes
you probably have missing or invalid C libraries or headers. In the case of nokogiri you're hidding well known pathological incomplete-C-library-bundle-in-gem issues that I think are representative of a very complex web of problems where gem maintainers and operating system maintainers are each doing stuff unaware of stuff the other person is doing. The wonderful nokogiri people have given us options to get out of cases that they can't automate away,:
cd ~/gitlab/gitlab-development-kit/gitlab
# work around nokogiri and libicu pathological library issue:
bundle config build.nokogiri --use-system-libraries
bundle install --without mysql production --jobs 4
On OpenSuse Tumbleweed, the most problematic gem is charlock_holmes
, due to libicu
unicode library issues.
Something that has been reported to work with charlock_holmes
when people have libicu issues but which did not work for me yet, is to specify an icu directory like this, on Tumbleweed:
bundle config build.charlock_holmes --with-icu-dir=/usr/local/lib64
If you get part way through a gdk install and it fails, it might be a good idea to just go up a directory and rename your old gitlab-development-kit folder to something else add restart from the gdk init
stage, then cd into the new directory and re-run gdk install
as gdk update
can not resume in the case where the initial gdk install
failed.