Category Archives: Gitlab

Jenkins Gitlab Hook Plugin reorganized

The Jenkins Gitlab Hook Plugin received a major refactoring. The goal was to separate concerns from existing modules and to make the project testable. Github repo now contains Java binaries needed to run the rspec tests, but hopefully you’ll find the new organisation a bit more intent revealing and easier to follow.

I’ve used the use case approach, and extracted related services so now all the domain knowledge is contained within models sub folders:


The remaining models in the root models folder are all directly Jenkins related and left there so Jenkins can load them first and register the plugin and the related web hook correctly.

The entire domain knowledge is now also testable. I chose the rspec to run the tests and have created the related spec helped that loads all the Java dependencies and models from the root folder. To run the specs, you’ll need to setup JRuby so it runs in Ruby 1.9 compatibility mode. Just add the following switches to your JRUBY_OPTS environment variable: –1.9 -Xcext.enabled=true -X+0.

The v1.0.0 release has all the goodies, so feel free to upgrade your Jenkins environments.

Tagged , ,

Jenkins Gitlab Hook plugin updates

There have been a few changes to the Jenkins and the related Ruby runtime as of late. This has caused a few issues with the Gitlab Jenkins Hook plugin which have finally been resolved.

It is recommended that you upgrade to the latest plugin version v0.12.2 and Jenkins to the latest available version if possible. Otherwise, I would stay away from Jenkins v1.519 to v1.521 and the plugin version v0.2.7 to v0.2.11. If you are not experiencing any issues currently, that’s OK, this is related only to those that want some part of the system upgraded for whatever reason.

Also, the upgrade is recommended if you have any of these symptoms:

  • Failed to load HAML message – problem with Ruby Runtime on windows, details in issue #9
  • Failed to install the plugin – problem with Ruby Runtime and Jenkins v1.519 and  v1.520, details in issues #10#11, #12 and #13
  • Undefined method ‘getDefaultParametersValues’ – method gone private in Jenkins, details in issue #14
  • Build no longer triggering – plugin was not building non parametrized Jenkins projects, details in issue #15

  • Case insensitive repo URL matching



Tagged , ,

Http clone with LDAP authentication in Gitlab

I’m beginning to change the title of the blog to Gitlab something 🙂 But, it is the current focus at my day job, so it can’t be helped. Anyway, LDAP Gitlab web UI is pretty easy to setup and use. And it works beautifully. Devise and omniauth are driving it and that is pretty much it. However, if you like to have HTTP access repositories, and use LDAP to authenticate users, it wouldn’t work. The reason is that UI access goes through Devise, but repo access actually doesn’t. The grack_auth.rb is the key to the repo access process.

The main idea is to use plain ruby Net LDAP gem to authenticate the user directly against LDAP, while using Gitlab provided LDAP settings. I couldn’t find a way to hook this into Devise flow, hence this approach. If anybody knows how to manually authenticate using Devise, please let me know?! I suppose in some future versions Gitlab will solve this but for versions <= 3.1.0, this is usable and actually works in production environment at my day job.

There are actually two versions of the fix. Latest version, that applies to latest master, assumes username for the User is filled in when user is added after first time login (or updated later). Stable (3.1.0 or less) fix works a bit differently, it first tries to authenticate user with LDAP and uses the provided user email to continue. More details can be found in the provided gists:

* latest / master version:
* stable (<=3.1.0) version:

Feel free to apply at your environment and let me know if it works.

Update: found another approach @ It is not a pull request but maybe you’ll like this approach better.

Tagged ,

Gitlab upgrade from 2.x.x to 3.1.0

Just some quick notes on Gitlab upgrade I did today. Some serious issues arose, due to me not being careful. Somehow part of the users managed to enter SSH keys while upgrade was taking place. Still don’t understand how, but some of the keys ended up having invalid content in /home/git/.ssh/authorized_keys and in /home/git/.gitolite/keys/[name of the invalid key]. This manifested in a very strange manner:

  • a part of the users had no issues using Gitlab
  • and others couldn’t clone or push to projects they have been given access to in Gitlab web

After loosing myself for quite a bit, finally this Gitlab issue led me in the right direction. After comparing keys in database and in above two locations, I found the differences and deleted the surplus keys and also invalid ones. I seems that Gitlab or Gitolite probably “loop”  through keys somewhere and this loop breaks for users below the invalid keys, or works OK for those above.

And a short recommendation for future reference: backup everything !!!

References: (latest setup instructions) (migrating Gitolite)

Tagged ,

Gitlabhq +1

About a few months ago, I had the opportunity to tryout and decide on the Git ecosystem. Out of the few existing solutions, like Gitorius and others, I finally settled on Gitlab. The setup procedure was pretty straight, although not as automated or easy as I would like it to be. Some work is done to speed up the process but for those in need or the impatient ones, you can always follow the default instructions, and apply additional recipes where needed.

Since then, the Gitlab web interface and the entire ecosystem kept running like a charm, no glitches and everyone is pretty much happy with it.

I’ve personally chosen to set it up on CentOS, for which there is a good guide, and in the above recipes you can find specifics for the given OS. Ruby compiling is what actually took the most time, but with the mentioned resources you shouldn’t have a hard time.

The only issue left is the project <=> user relation. Using LDAP for the domain , it integrates nicely with Gitlab, authentication wise. Unfortunately, there is no way to automatically add projects to the new user based on some rule. A relation between LDAP groups and projects would be nice. I read that in the latest release there is support for project groups, so maybe this will solve the issue, have to try it out soon. For now, we settled on adding all projects to all user. A rake task is used for this:

desc "Add all users to all projects (admin users are added as masters)"
task :add_users_to_project_teams => :environment do |t, args|
  user_ids = User.where(:admin => false).pluck(:id)
  admin_ids = User.where(:admin => true).pluck(:id)

  Project.find_each do |project|
    puts "Importing #{user_ids.size} users into #{project.code}"
    UsersProject.bulk_import(project, user_ids, UsersProject::DEVELOPER)
    puts "Importing #{admin_ids.size} admins into #{project.code}"
    UsersProject.bulk_import(project, admin_ids, UsersProject::MASTER)

desc "Add user to as a developer to all projects"
task :add_user_to_project_teams, [:email] => :environment do |t, args|
  user = User.find_by_email
  project_ids = Project.pluck(:id)
  UsersProject.user_bulk_import(user, project_ids, UsersProject::DEVELOPER)
Tagged , ,