Релиз GitLab 4.0 и GitLab CI

в 10:07, , рубрики: continuous integration, Git, github, gitlab, open source, метки: , , , ,

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

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

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

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

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

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

Скриншоты

Дешборд

Релиз GitLab 4.0 и GitLab CI

Merge Request

Релиз GitLab 4.0 и GitLab CI

File browsing

Релиз GitLab 4.0 и GitLab CI

Issues

Релиз GitLab 4.0 и GitLab CI

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

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

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

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

GitLab Continuous Integration Server

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

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

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

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

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

  1. GitLab на GitHub
  2. GitLab CI на GitHub
  3. GitLab.org

Автор: shebanoff

Источник

Поделиться

* - обязательные к заполнению поля