Talk:Gitlab

From ArchWiki
Jump to: navigation, search

Missing Section?

It might just be me, but it seems like a section is missing. In start and test it says visit your domain, however unless I am missing something pretty major that shouldn't work since neither apache nor nginx are ever setup / pointed to the webapp.--Theflyingfool (talk) 08:15, 8 April 2014 (UTC)

I don't have neither of them on my server, Gitlab uses own one, Unicorn, to deal with webapp. Kosciak9 (talk) 12:17, 6 December 2015 (UTC)

This has been explained, closing. -- Lahwaacz (talk) 19:43, 14 November 2017 (UTC)

Resolving dependencies and testing gitlab on remote server

This is a reply to the question above, as well some things that was missed during the installation I made.

I'm not sure if it should be added, so I'm putting it here for discussion:

You should install the following packages, before installing the GitLab from AUR:

Also, after finally starting the gitlab with unicorn, if you have installed gitlab on a remote server and not locally, you won't be able to access it using domain:8080. It is even mentioned in /etc/webapps/gitlab/unicorn.rb. In order to be able to access it, I have changed 127.0.0.1 to the servers IP, and made sure that shell.yml reflect the change as well (including the port).

After restarting the daemons, I was able to access giltab using domain:8080.

Tahvok (talk) 09:18, 15 May 2014 (UTC)

Closing as not applicable anymore - gitlab is in the community repository now and the IP addresses are properly explained on the page. -- Lahwaacz (talk) 19:50, 14 November 2017 (UTC)

nginx

After completing the steps above I continued to nginx installation, however, being not familiar with nginx it took me some time, so I'll put it here for discussion as well. This is the full guide, I know that some things are already mentioned in the page, just not very organized.

After installing nginx, it is mentioned that you should make the following command:

# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab

However, it will not work, since there is no site-available or sites-enabled directories, with include section in nginx.conf. It is true however in debian installations, but since we're in arch everything comes with no changes from the distro side.

Since there was no site-available file to copy the vhosts from, I read the official gitlab guide, and found that the file is located in /usr/share/webapps/gitlab/lib/support/nginx/ after installing the gitlab package.

I just put everything inside the file to nginx.conf inside the http section, just before the last }, and changed the following:

  • server_name to reflect my server's domain.
  • Set proxy_pass config to reflect unicorn listening address. I just put localhost:8080 in nginx.conf and set back unicorn.rb to point to 127.0.0.1 as it was before (including the port 8080).
  • Inside upstream gitlab set server to point to unix:/usr/share/webapps/gitlab/tmp/sockets/gitlab.socket; - I'm NOT sure about this. I also had a permissions problem, so I changed group permission to http for the sockets folder.
  • Point the config root to /usr/share/webapps/gitlab/public;
  • Comment out the gzip section - it was not working for me, and made the site with no assets, so I didn't bother with it.

Edit shell.yml as follows:

gitlab_url: "http://domain/" - domain is the same as server_name in nginx.conf.

Also make sure that in gitlab.yml the host is set to your domain and the port is the same as in nginx.conf.

Restart the daemons:

$ systemctl restart gitlab-sidekiq gitlab-unicorn nginx

Should be working now.

As I said, this is my rough way of installing it, so before I put it on the page, would like to know if that's the right steps.

Tahvok (talk) 09:18, 15 May 2014 (UTC)

The page points to /usr/share/doc/gitlab/nginx.conf.example and Nginx#Managing server entries now. There is no place on this page to teach nginx basics and everything that Gitlab needs should be in the example file. Closing. -- Lahwaacz (talk) 19:56, 14 November 2017 (UTC)

Using Sudo instead of su -

I don't have any root password on my pi, only my user password (for sudo). As the rest of the documentation uses sudo, it would be better to use sudo here too : https://wiki.archlinux.org/index.php?title=Gitlab&section=13

For some reason all sudo - commands fail for me, not sure why. ElectricPrism (talk) 08:10, 21 December 2015 (UTC)

I'm also having issues without being root, unfortunately there are more issues, and I couldn't install (the latest version) at all.
Going to add Stub template, because more commands listed doesn't seem to work (correctly).
Beta990 (talk) 11:42, 21 December 2015 (UTC)
Note: Regarding the `su - gitlab` users have gotten a update because they kept failing for me too.

Very confusing

I went through the install, I didn't make it work yet but I have a few questions on confusing instructions:

-I want to use my already set-up nginx webserver. Should I still use reddis, and the gem/bundle install commands ?

Yes, you should proxy-pass nginx to unicorn. Redis is used for internal communication, gem/bundle for setup. You can find good explanations at the GitLab website. DenBrahe (talk) 21:43, 19 April 2016 (UTC)

-What are the pros/cons to use the AUR package v. using the official package ?

AUR package is finetuned for Arch to work with systemd and linux conventions and things like that (don't know exactly). Basically if you're not an expert, you're better off with the AUR package. Wiki page should get an update though. DenBrahe (talk) 21:43, 19 April 2016 (UTC)

-How can we uninstall the components installed by the gem/bundle install commands ?

-the su - gitlab command is not working but sudo -u gitlab works (as mentionned in this thread), is that ok ?

-I don't have any shell.yml file, which is mentionned only once for the HTTPS configuration, is it normal ?

-what is /dev/null in the nginx config ?

-how do I setup resque.timer ? I can't load it? ('unit resque.timer not found).


Mentatf (talk) 22:41, 7 April 2016 (UTC)


I am adding my two cents to this section as well, because after trying for around 5 hours, I am giving up on the gitlab package and will try Gogs/Gitea instead. As I cannot say for sure what are actual problems and which are design choices made by the package maintainer that are just not well documented, someone else who has the necessary knowledge has to decide which changes are appropiate to make.

This is summary of the problems/confusion I faced:

  • The package depends on ruby2-3, which does not provide the bin 'ruby'. This throws off the environment check at the very least, yet no note is made of that.
  • Despite stating that the Arch package uses the user gitlab instead of git, the latter keeps getting mentioned in the article, sometimes even together with gitlab.
  • As described below, rvm seems to be neither necessary nor supported, yet the article implies that its usage is good practise.
  • All GitLab files seem to belong to root, leaving the gitlab with insufficient rights to save config files. As a result, at the very least the copy&paste solutions provided by the environment checks cannot be used because of that.
  • The article states that Unicorn is a HTTP server on its own, yet GitLab is shipped with nginx by default.
  • The article says that gitlab-workhorse is optional, yet at the very least the current Apache examples provided by GitLab all assume it to be configured. The package itself also depends on it.

Right now, it might be a better idea to intall GitLab from source, as the official documentation is more up-to-date and can be used with less adjustments. --Krukai (talk) 09:15, 8 September 2017 (UTC)

Another small thing: the wiki page says we should enable gitlab-sidekiq and gitlab-unicorn services, but these are already part of gitlab.target, so I believe there is no need in enabling them separately. --Nplatis (talk) 06:04, 26 September 2017 (UTC)

Check that the secret file exists

The Initialize Gitlab database section tells us to check if there's a secret file at /etc/webapps/gitlab/secret, while the file is found at /etc/webapps/gitlab/secrets.yml now. Sava (talk) 08:21, 25 September 2016 (UTC)

Regarding 'Running GitLab with rvm'

According to Gitlab#Running_GitLab_with_rvm, Ruby version 1.9.3 is recommended. However, GitLab seems to recommend 2.3 since at least v9.2.1: [1]. Also, the section is not very clear whether rvm should be downloaded as the new user or not. It seems that this should be the case, but the section only mentions it after the first step. Finally, it refers to the user git, while Arch installs Gitlab for the user gitlab by default. Does the section need to be updated, or am I missing something here? Right now, I feel like installing GitLab without rvm. --Krukai (talk) 09:50, 6 September 2017 (UTC)

This section still needs to be updated. I haven't performed a test of that topic yet. Feel free to update that section as I don't plan to use Gitlab with rvm any time soon (at least professionally). Regards. -- wget (talk) 14:54, 6 September 2017 (UTC)
Thanks for the heads-up, but I don't see any reason right now to use rvm, either, as the package depends on exactly the Ruby version needed. I assume that once GitLab moved to Ruby 2.4, the package maintainer will as well. Perhaps the section could use a note indication something along those lines. --Krukai (talk) 15:17, 6 September 2017 (UTC)
I'd say remove this section altogether. RVM is not officially supported. --Maevius (talk) 17:22, 7 September 2017 (UTC)
I went ahead and removed it as well as the SQLite section, that was veeeery old. --Maevius (talk) 09:42, 15 October 2017 (UTC)
Closing. -- Lahwaacz (talk) 17:36, 14 November 2017 (UTC)

Rewrite of the article

Hello everyone. If I look at your comments, we clearly see there is an issue with this installation guide. I talked on IRC with Sven-Hendrik Haase, the maintainer of the gitlab package, and it seems only him has abilities to make this package 'work' properly without issue. Being the packager and knowing how Gitlab internals working is clearly an advantage, but this isn't the case for the newbie/simple Arch Linux user just wanting to have Gitlab installed in a matter of minutes. This is why I decided to completely rewrite this page. Please let me know your idea and comments wrt. this rewrite. New commits are ongoing. -- wget (talk) 13:46, 19 November 2017 (UTC)

I've also recently successfully set up Gitlab using the Arch packages. There are a couple of things specific to my setup which are not mentioned on this page, but overall I don't see a need for a rewrite. It would also be hard to impossible to compare the differences from the current page. If you do that anyway, please use your user page for the draft. -- Lahwaacz (talk) 15:02, 19 November 2017 (UTC)
What I mean by rewrite, the structure won't change, this is basically the same but all sentences have been reworded, because when you come along as a newbie, the package split seems weird and you do not know the different parts that constitutes Gitlab. But anyway, no worry, I can use this page is you want me to. I'm quite used in rewriting article (VirtualBox for example is a topic I have rewritten two years ago, Odoo and Mattermost as well). Since you're here, I have a question I would' like to ask you wrt. MediaWiki syntax with ArchLinux specific templates. I used bullet points in my rewrite:

MediaWiki formatting question

  • In the database config file /etc/webapps/gitlab/database.yml, for the sections production and development (not test, unless you know what you are doing), replace the fields with the credentials created above.
/etc/webapps/gitlab/database.yml
[...]
database: gitlab_database
[...]
username: gitlab_database_user
password: "gitlab_database_password"
[...]

How do you prevent the header split in this case. ^ As you can see the file content is not shifted as well while I made sure I used the trailing colon (:)? -- wget (talk) 16:09, 19 November 2017 (UTC)

I managed to do it like this by opening table (template did eat it, so that seems risky to me):
/etc/webapps/gitlab/database.yml
[...]
database: gitlab_database
[...]
username: gitlab_database_user
password: "gitlab_database_password"
[...]
Help:Editing#Indenting says only when strictly necessary to obtain the desired layout that actually means w:Don't talk to me or my son ever again - you can see how bad indentation is on the picture. -- Svito (talk) 10:04, 27 November 2017 (UTC)
Thanks this seems to be reasonable to me even if this seems discouraged by MediaWiki best practices, but this will allow the article to have better understandability IMHO. -- wget (talk) 09:30, 1 December 2017 (UTC)
Note that the table created by Svito was originally not closed (I just fixed that) so you can see how tricky it is. The problem is with Template:hc which has a linebreak between the two <pre> tags which is unfortunately necessary. It is explained in a comment in the template, but basically the problem is that if a <pre> tag appears later than at the beginning of the line, it is rendered incorrectly with <p> tags inside. You can see it here:
foo

bar
foo

bar

-- Lahwaacz (talk) 12:09, 1 December 2017 (UTC)

Old configuration info

Recently tried to setup gitlab/nginx by instructions on this page, but they are quite legacy for current version on community repository (config lines, locations, not-existent files). Any maintainer here? =)

—This unsigned comment is by Llorephie (talk) 22:14, 4 December 2017‎. Please sign your posts with ~~~~!

Corrections are always welcome so feel free to flag the inaccuracies with Template:Accuracy or just fix them if you know what is correct. As for the config snippets, I think they are mostly unnecessary as the default files are heavily commented, so it would be enough to describe what to look for. -- Lahwaacz (talk) 22:37, 4 December 2017 (UTC)
Indeed this article is a nightmare. I'm currently completely rewriting it, but I'm only able to work an hours a day on it. The rest of my FOSS time is devoted to maintaining some AUR packages. Please continue noticing issues about Gitlab on Arch Linux or simply modifying this document. I'm taking actions. :) -- wget (talk) 23:03, 4 December 2017 (UTC)
Today I got some time for more detailed reading and editing, so I hope it's better with my updates. -- Lahwaacz (talk) 20:28, 5 December 2017 (UTC)