Релиз GitLab 4.0 и GitLab CI

Конец 2012 года прошел в суматохе, и каким-то образом я упустил из внимания две важные новости: в декабре вышел GitLab 4.0 ^[1], а на середину ноября пришелся релиз GitLab Continuous Integration Server ^[2].

GitLab ^[3] — это замечательное FOSS решение для хостинга ^[4] git-репозиториев внутри закрытой инфраструктуры. Функционал во многом аналогичен GitHub, в частности доступны базовые возможности администрирования и разделения полномочий между пользователями, issue трекер, вики, code review и мердж реквесты (аналог пулл-реквестов на GitHub). И внеочередной плюс теперь, как по мне — это интеграция с GitLab CIS.

GitLab CIS ^[5] — если GitLab послужит Вам заменой GitHub, то GitLab CIS призван стать заменой Travis CI. Набор фич соответствующий: запуск по git push, отдельные билды под бранч, интеграция с любыми git-репозиториями и бейджик со статусом текущего билда.

Причины для поиска и использования self-hosted решений для содержания кода у всех могут быть разными, но в большинстве своем они вполне очевидны и обусловлены поиском безопасности и прозрачности, чего невозможно добиться при использовании SaaS.

Что примечательно, работу ведут и курируют скромные украинские парни Дмитрий Запорожец и Валерий Сизов ^[6].

GitLab 4.0

Изменения в поведении приложения:

• Новые проекты получают отдельный неймспейс (к примеру gitlab/vagrant )
• Каждая группа имеет свою директорию в gitolite
• Все проекты группы будут перенесены внутрь ее директории (нужно обновить git remote)
• Проекты без группы останутся на своих местах
• У пользователей появляются юзернеймы (для существующих пользователей они будут сгенерированы основываясь на адресе электронной почты)
• Пользователь создает проект в своем неймспейсе (например randx/my-project)
• Пользователь может менять свой юзернейм. Все его проекты будут соответствующим образом перенесены
• У группы есть владелец
• Владелец может создавать проекты внутри группы
• Владелец имеет доступ ко всем проектам внутри группы
• Администратор может переносит проекты из одного неймспейса (группы, пользователя, глобального) в другой
• Группа или пользователь — неймспейс для проекта. Владелец неймспейса — владелец проекта

Другие изменения

• Улучшенная поддержка PostgreSQL
• Добавлено email уведомление о перемещении проекта
• Исправлено email уведомление при открытии/закрытии issue
• Реорганизованные настройки
• Исправлено сравнение коммитов
• Обновлен интерфейс, теперь можно скачать патч или дифф для коммита и мердж реквеста
• Майлстоуны теперь можно закрывать. Майлстоун остается открытым, пока его не закроешь.
• На дешборде отображаются новые комментарии
• Быстрое добавление членов команды на странице group#people
• Улучшения интерфейса
• В разделе администратора проекты, пользователи и группы сортируются по алфавиту
• Улучшена страница управления Issue на дешборде
• Улучшена интеграция с GitLab CI (требуется GitLab CI v1.1.1)

Что было удалено в 4.0:

• Поддержка gitolite 2
• Поддержка SQLite (штука конечно хорошая, но эта БД блокируется, когда ей пользуются несколько пользователей одновременно)
• Поддержка API v2 (из-за несовместимости с неймспейсами)

Что нужно обновить во время переезда:

• Конфиг gitlab.yml
• Post-receive хуки gitolite
• Права доступа к /home/git/repositories/
• Симлинки python2

Скриншоты

Дешборд

Merge Request

File browsing

Issues

Как переустановить gitolite

• Инструкция по переустановке ^[7]

Как переехать с sqlite

• Инструкция по переезду ^[8]

Как установить GitLab v4.0.0

• Полное руководство по установке (рекомендовано) ^[9]
• Скрипт инсталляции для ubuntu 12.04 x64 ^[10]

Как обновить GitLab до v4.0.0

• Инструкция для v3.1 ^[11]
• Инструкция для v3.0 ^[12]

GitLab Continuous Integration Server

Ключевые моменты

• GitLab CI работает на Ruby on Rails + Resque/Redis
• GitLab CI поддерживает только git
• Для автоматической сборки требуется работающий инстанс GitLab

Как это работает

1. Для начала нужно установить GitLab CI на VPS ^[4] или любой linux сервер
   
2. Затем нужно склонировать проекты, которые будут в будущем тестироваться и настроить тестовое окружение
3. Следующим шагом надо просто добавить проекты в GitLab CI с помощью веб-интерфейса
   
4. Остается только скопировать HTTP POST url предоставленный GitLab CI в вебхуки GitLab
   
5. При пуше в репозиторий сработает хук, который и заставит CI начать сборку

От себя добавлю, что проекты действительно стоящие внимания. Не пропустите.

1. GitLab на GitHub ^[3]
2. GitLab CI на GitHub ^[5]
3. GitLab.org ^[13]

Автор: shebanoff

Источник ^[14]