Notes on installation, configuration, and use of gitlabhq:


Based on politics and advice from puppet enterprises, we’re working on a code review process for puppet. Additionally, our SCM team is going to need something gui in order to manage git because they’re afraid of the command line.

Since we don’t have a budget for this thing, enter gitlabhq. Since I’m the one familiar with git, I’m tasked with figuring out gitlabhq. Entertaining, that, as I know absolute beans about the SDLC process and how it actually works in the real world...


So, to review the major app components and issues to date:

  • Git is a distributed version control system. Quite versatile and, apparently, what the industry is going to, according to the SCM MFWIC
  • gitolite is the app that we have been using to control access to the repos. Not exactly intuitive, but once configured, an incredibly useful tool. We can control access down to the file level which just makes the security guy in me drool. It uses ssh/pka only, another good thing, and the biggest one for recovery: it can mirror repos - at the repo level - across many systems. Excellent for DR and local access to repos. It doesn’t have a gui front end and there’s no clean way to do any type of code review
  • gitlabhq: front end to git that provides a procedural structure for code review. Supposedly provides access control to the repos. Does not show any evidence of any type of mirroring functionality.


gitlabhq book purchased from amazon. `Gitlab repository management`_

The book covers installation from scratch using ruby and ubuntu apt packages.

Configuation, too, is somewhat more involved than is the case on rhel variants as most of that is handled by the package.

Things to do:

  • (done) Get local mail relay going on node1
  • (done) Practice a work flow:

Lessons learned:


control program for gitlabhq.


  • Install/configue dependencies:

    • yum install curl openssh-server postfix cronie
    • service postfix start
    • chkconfig postfix on
    • lokkit -s http -s ssh # opens ssh/http ports on iptables fw
  • Add gitlab repo and install the package:

    curl \ | \
    yum install gitlab-ce
  • Configure and start gitlabhq: gitlab-ctl reconfigure

  • Browse to hostname and log in root/5iveL!fe

Configuration files:


  • Unlike what the book says, this file is managed by gitlab-ctl. Changes will be erased.

  • Reading the comments in the file:

    • No symlinks anywhere in the repo path:

      # Repositories path
      # Give the canonicalized absolute pathname,
      # Check twice that none of the components is a symlink, including "/home".
      repos_path: "/var/opt/gitlab/git-data/repositories"
  • Log file: /var/log/gitlab/gitlab-shell/gitlab-shell.log

    • Tracks repo creation and key addition.
    • not sure what else.
  • audit_usernames looks useful.

    # Audit usernames.
    # Set to true to see real usernames in the logs instead of key ids,
    # which is easier to follow, but
    # incurs an extra API call on every gitlab-shell command.


  • No surprises.


  • eamil_from: Sets the ‘from’ address of emails
  • ldap settings go in this file; clear text bind_dn and pwd...


No surprises.


  • I ran through the installation process several times w/o issue. The instalation’s not the problem... what to do next is.. how do you use this damned thing?

  • Looks like the generic installation uses postgesql

  • Book goes over some innocuous and, in at least one case, stupid sshd configuration changes. Change the ssh port... have you heard of nmap? dumbass

  • Creating users is pretty straight forward.

  • Gitlab API is interesting.

    • It uses a token for authentication available under profile settings -> account.
    • Can’t seem to get it to work with curl but some of examples in python that I’ve seen look pretty simple.
    • There is a gitlab-api-v3 perl script available; but, I ran into dependeny hell when I tried installing and running it.
      • perl -M CPAN -e shell
      • install strictures
      • install Moo // LOTS of pre-reqs
      • install namespace
      • And, still no joy... fuck
    • Need to get that working. Installing 100s of users is going to flipping suck great big hairy donkey balls.
  • Into chapter 4, got 10 sample uses in 3 different teams loaded. Should give me something to play with re uses.

  • Git markdown - used for wikis:

    • @ = team members @foo
    • # = issue numbers #123
    • !123 = merge request
    • $123 = snippets
    • 1234567 = commits
  • Chapter 5 was a bit of a skim. Went over issues, wikis, and the personal code a bit. nothing too special.

  • Work flows - this one should be the big one.

    • Single branch:

      • Multiple developers all working on the same branch.
      • Pros:
        • simpler
        • Everyone has a consistent view
      • Cons:
        • Discourages experimentation
        • No proposal for code changes - just straight implementation.
    • Feature branch:

      • Branch per feature; when considered done, the branches are merged back into the master branch

      • Steps to create a feature branch:

        git clone ${proj} || git pull # as needed.
        git branch ${feature}   # creates the branch
        git checkout ${feature} # switches to the branch
        git push origin ${featue}
  • OK: that was anticlimactic...


So, working through the process a time or two to see how this works.

I installed gitlabhq on a kvm, created a number of users, and copied over my lessons leared repo. I’m able to access it as user dkoleary - the project owner.

I just added several member one of which is jroess, to the project and am now trying to update a change from the miscreant. All members are added as developers. I just tried to create a file as young jroess, commit, and push with this result:

[jroess@node1 git]$ git push
Warning: No xauth data; using fake authentication data for X11 forwarding.
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 487 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: GitLab: You are not allowed to push code to protected branches on this project.
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to ''

Now, branching out:

[jroess@node1 git]$ git checkout -b git
Switched to a new branch 'git'

[jroess@node1 git]$ git log --oneline -5
8d7977f git:gitlabhq addition and suggested sections
63a8eae puppet:tak2 - progress
ceb4e0a spacewalk: corrected typo

[jroess@node1 git]$ git branch
* git

And, finally, to push the new branch:

[jroess@node1 git]$ git push origin git
Warning: No xauth data; using fake authentication data for X11 forwarding.
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 487 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
 * [new branch]      git -> git

OK: played around with comments, merge requests, accepting, and deleting. Not that intuitive; but, I’m going to have to show Justin the comments he wrote. Very unprofessional!