I then came across the Groups feature within the admin area. This 100% was not the right thing to do, since deleting that user would delete all of the companys codebase along with it! Originally i created a user called with the name of our company and figured that admin users could just “impersonate” (an awesome admin feature that lets you pretend to be another user and see / interact with the system as them) the company user to create new project repositories. Normally this would be the expected behaviour and totally fine for my own work, but when working on company projects it wont do, we’d want something like company-name/project-name which could then be forked by other users. Gitlab groupsīy default if I as a user were to create a repository within gitlab it would exist under my username’s namespace, forexample : talv/my-project. The next thing I did was create some of the users for the system set up SSH keys (really easy to do within the admin area), create some groups and then begin importing our existing projects into the gitlab. Log into gitlab and start setting up your users and repositories!.Reconfigure gitlab to make changes take effect 1 Gitlab_rails = 'none'Īdd the following to the bottom of the file 1
HOW TO INSTALL GITLAB IN UBUNTU 16.04 INSTALL
Sudo apt-get install curl openssh-server ca-certificates postfixĬonfigure gitlab to send E-mails via SMTPįind the “GitLab” email server settings” section update and it and uncomment it to suite your email server settings I’m fortunate to be starting the process off with a freshly installed Ubuntu 16.04 LTS server, thats been fully upgraded. Importing old repositories into the new gitlab instance.Setting up postfix to send emails from out mail server using SMTP.Changing the storage directory for git repositories.The gitlab install process is straight forward, just follow the CE documentation.īefore i started anything I checked that all of the projects I wanted to migrate had been checked out on my local machine along with all of the branches of those projects that I wanted to keep (another benefit over gitolite should bring is the ease of identifying old branches within a repository that can be removed!).īeyond the base install I’ll be covering the following: Mostly for my own reference I’m going to detail the steps I’ve gone through to get our gitlab instance set up. Gitlab is very similar to github in what it offers but with one big difference, it offers a community version that you can self host. However our business wanted to keep everything on our own servers - hence the original gitolite set up. Since I used github for my own projects it would have been ideal for us to move to the paid plan over there to keep our repositories private. Which are all features that github has built in natively. It also requires you to have all of the following tools separately: One of the things gitolite doesn’t provide you with is any sort of front end at all, everything has to be done through the terminal. We also use a satis install to act as a private composer for our internal private packages. The same config file could then be used to determine which access rights they had to repositories as well as defining new repositories. Its worked well, and after some initial configuration (which I recall being pretty tricky) looking after the gitolite instance has been pretty easy and could easily continue to serve our needs as a small business well.Īdding new users required you to get an ssh key from the new user, add it to an “administration repository” and then add their name to a config file within that repository. Where I work, we’ve been using an Ubuntu Server running gitolite to act as our “Source control server” and manage permissions and access.