GitLab 4.0 and GitLab CI release

The end of 2012 was passed in turmoil, and somehow I missed two important news: GitLab 4.0 came out in December, and the GitLab Continuous Integration Server was released in mid-November.

GitLab is a great FOSS solution for hosting git repositories inside a closed infrastructure. The functionality is in many respects similar to GitHub, in particular, the basic features of administration and the separation of powers between users are available, issue tracker, wiki, code review and merge requests (analogue of pull requests on GitHub). And an extraordinary plus now, as for me - this is integration with GitLab CIS.

GitLab CIS - if GitLab serves as your replacement for GitHub, then GitLab CIS is meant to be a replacement for Travis CI. The set of features is appropriate: launching on git push, individual builds for brunch, integration with any git-repositories and a badge with the status of the current build.
')
The reasons for finding and using self-hosted solutions for the content of code can be different for everyone, but for the most part they are completely obvious and driven by the search for security and transparency, which is not possible with SaaS.

Remarkably, the modest Ukrainian guys Dmitry Zaporozhets and Valery Sizov are leading and supervising the work.

GitLab 4.0

Changes in application behavior:

New projects receive a separate namespace (for example, gitlab / vagrant)
Each group has its own directory in gitolite
All projects of the group will be transferred inside its directory (you need to update git remote)
Projects without a group will remain in place
Users have usernames (for existing users they will be generated based on the email address)
The user creates a project in his namespace (for example randx / my-project)
The user can change his username. All his projects will be transferred accordingly.
The group has an owner
The owner can create projects within the group.
The owner has access to all projects within the group.
The administrator can transfer projects from one namespace (group, user, global) to another
Group or user - namespace for the project. Namespace owner - project owner

Other changes

Improved PostgreSQL support
Added email notification about moving project
Fixed email notification when opening / closing issue
Reorganized settings
Fixed commit comparison
Updated interface, now you can download a patch or diff for a commit and merge request
The milestones can now be closed. Milestone stays open until you close it.
New comments are displayed on the dashboard.
Quickly add team members on group # people
Interface improvements
In the admin section, projects, users and groups are sorted alphabetically.
Improved Issue management page on the dashboard
Improved integration with GitLab CI (GitLab CI v1.1.1 required)

What was removed in 4.0:

Gitolite 2 support
SQLite support (a good thing, of course, but this database is blocked when several users use it at the same time)
API v2 support (due to incompatibility with namespaces)

What needs to be updated during the move:

Config gitlab.yml
Post-receive gitolite hooks
Permissions to / home / git / repositories /
Python2 symlinks

Screenshots

Deshbord

Merge request

File browsing

Issues

How to reinstall gitolite

Reinstallation Instructions

How to move from sqlite

Relocation instructions

How to install GitLab v4.0.0

How to upgrade GitLab to v4.0.0

GitLab Continuous Integration Server

Key points

GitLab CI works on Ruby on Rails + Resque / Redis
GitLab CI only supports git
For automatic assembly, a working GitLab instance is required.

How it works

First you need to install GitLab CI on a VPS or any linux server
Then you need to clone the projects that will be tested in the future and set up a test environment.
The next step is to simply add projects to GitLab CI using the web interface.
All that remains is to copy the HTTP POST url provided by GitLab CI to GitLab webbooks.
When pushing to the repository, a hook will work, which will cause CI to start building