Категория: Руководства
Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.
Continuous integration — это не только запуск юнит тестов при пуше нового кода в репозиторий. Это еще и возможность делать сборки продуктов, публиковать их в сторы, на сайты и в другие каналы распространения. Облачная телефония voximplant использует javascript сценарии, которые размещаются в нашем облаке и выполняются по команде “снаружи” или при поступлении входящего звонка. Многие клиенты для работы со сценариями используют встроенный в админку текстовый редактор, что вполне подходит для простых случаев. Но при разработке и поддержке сложных облачных систем, к примеру телефонии Bitrix24, нужно что-то более серьезное.
Создавая voximplant мы решили не делать push-to-deploy как у heroku. У многих наших клиентов основной бизнес не связан с разработкой софта, и оставлять их один на один с git’ом не очень хорошо. Зато есть HTTP API с функцией “задеплоить сценарий”, который намекает понимающим людям что сценарии можно хранить на gitlab и деплоить с помощью shell скрипта и curl. Большинство клиентов так и делает, но у подхода есть серьезный недостаток: скрипт нужно не забыть вызвать. Более того, вызывать его надо только если код был запушен в production ветку. И только после того, как прошли тесты. Вообще много способов ошибиться.
По умолчанию continuous integration в гитлабе выключено и необходимо его включить в настройках:
После включения в левом меню настроек проекта появляется несколько новых пунктов, самый интересный для нас — это «runners». Continuous integration в гитлабе работает следующим образом:
Для нашего примера мы запустим runner на машине разработчика. Инструкции по установки для windows/linux/osx доступна на официальном сайте, после установки мы получаем в свое распоряжение command line утилиту gitlab-ci-multi-runner. Запущенный runner подключается к гитлабу и ждет задачи на сборку. Но как гитлаб узнает, какие задачи какому runner’у давать? Чтобы “привязать” runner к своему аккаунту и проекту (или нескольким проектам) необходимо вызвать gitlab-ci-multi-runner с ключем register и ввести параметры подключение: url гитлаб (так как гитлаб может быть развернут локально в вашей сети) и токен регистрации, который, собственно, и определяет аккаунт/проекты:
Зарегистрированный runner запускается командой gitlab-ci-multi-runner run и ждет задачу от гитлаба. С помощью ключей командной строки install и start runner можно зарегистрировать в системе как сервис, чтобы он автоматически стартовал после перезагрузки операционной системы.
Как я уже писал, задачи continuous integration описываются в файле .gitlab-ci.yml который необходимо разместить в корне проекта. Редкоземельный синтаксис YAML является как-бы-человекочитаемой альтернативой JSON’у, документация доступна на официальном сайте. Конфигурационный файл для деплоя проекта в voximplant будет максимально простым, все что нам нужно — это сделать один вызов HTTP API как описано в нашей документации. Если исходить из предположения, что runner выполняется на компьютере где установлен curl, а код сценария находится в файле scenario.js. то конфигурационный файл для деплоя будет выглядеть следующим образом:
В curl используется синтаксический сахар нашего API, которое может принимать аргументы как в компоненте query передаваемого url, так и в body http запроса.
Чтобы continuous integration заработал достаточно сделать push в репозиторий: гитлаб обнаружит файл .gitlab-ci.yml. найдет подключенный runner, передаст ему содержимое этого файла, runner обновит свою копию репозитория и запустит скрипт деплоя, который отгрузит исходный код в наше облако.
Вопросы, уточнения, комментарии? Gitlab vs Jenkins vs Bamboo vs Teamcity?
Задача: найти через GitLab API milestones для всех проектов, группы проектов, а также для выбранного проекта.
Т.е. нужно частично имплементировать в своем десктопном приложении то, что у них реализовано в веб гуи.
- Пытался задать в чатике - молчок.
- Где найти русскоговорящих контрибуторов, которые бы реагировали в гиттер чатике?
Зы есть ли вообще готовые десктопные клиенты для Gitlab?
Здравствуйте! Решил настроить себе GitLab и объединить его работу с Jenkins (уже был, и долго служил верой и правдой). Сделал всё по статье http://doc.gitlab.com/ee/integration/jenkins.html. и Jenkins стал прекрасно запускать job'ы при push'ах в GitLab.
Столкнулся с проблемой при настройке «Jenkins CI» в GitLab, его там нет и откуда его взять непонятно.
Может кто-то сталкивался с такой проблемой?
gitlab + doxygen не дружат
На работе стоит гитлаб, где есть куча проектов. Большая часть из них содержит подробную документацию внутри кода с использованием doc-блоков. На локальном компьютере документация отлично генерируется через doxygen.
Есть задача централизовано генерировать по всем этим проектам документацию на самом сервере gitlab и иметь доступ к ней. Причем, для оперативности процесса, хочется после каждого «git push» на gitlab-сервер, чтобы документация генерировалась заново.
То есть алгоритм такой: На сервер приходят новые коммиты, обновляется git-репозиторий, запускается doxygen по текущему git-репозиторию, doxygen складывает результат своей деятельности в определенную папку в которую смотрит веб-сервер и отдает оттуда результат.
Сейчас я написал post-recieve hook для git'a. Можно посмотреть тут - http://pastebin.com/MecjMUfs
Работает он так: Если в папке с проектом есть doxygen/Doxyfile.cfg, он генерирует имя проекта исходя из его пути и запускает doxygen.
Громадный недостаток в том, что этот скрипт нужно класть вручную в каждый проект на gitlab. Более того, в свежесозданные проекты его тоже нужно будет класть.
Как Вы решаете задачу генерации документации по своему коду?
Может я неправ и мне не нужно чтобы документация генерировалась автоматически? Может быть достаточно скрипта который будет по крону раз в день ходить по всем папкам gitlab-овских репозиториев и генерировать документацию раз в день?
Развернул гитлаб примерно следующим образом:
Морда и sidekiq работают нормально, но я ничего не могу сделать с репой. При попытке подключения по ssh мне предлагается ввести пароль от gitlab@host, хотя я создал отдельный ключ для своего логина, записал его через морду в гитлабе и убедился, что он попал в authorized_keys и что authorized_keys читается от пользователя gitlab, однако подключение все равно хочет, чтобы я ввел пароль от пользователя gitlab (http://pastebin.com/TmQDdxb0 ). Когда я добавил http remote (git remote add origin-http http://gitlab.domain.com/user/playground.git), у меня были запрошены логин-пароль, после чего мне было сообщено, что ремоута не существует (проект при этом вообще создан как public):
wtf и что делать?
задан 24 фев '14 в 5:00
Как всегда это бывает, проблема оказалась в поставленных на папку разрешениях. SSH отказывался работать, пока к папке ключей имела доступ группа владельца, ответ нашелся в /var/log/auth.log. Первое время пробиться по SSH все равно не получалось, я на всякий случай принудительно сменил шелл юзеру gitlab на /bin/bash (по идее никакого другого и быть не могло), и внезапно все запустилось.
Параллельно с этим в первый раз не создался сам репозиторий, поэтому не работал http-доступ. При успешном создании репозиторий должен появиться в виде git-файла в %repos_path%/%username%/%reponame%.git (например, /srv/gitlab/repositories/fike/playground.git ).
ответ дан 5 мар '14 в 5:45
Всем привет! В этой статье мы поделимся нашим непростым опытом установки замечательного open source решения GitLab. GitLab — это система управления исходным кодом для git. достойная альтернатива известным проектам GitHub, BitBucket и прочим онлайн git-хостингам. Но давайте обо всем по-порядку.
Что такое GitLab
GitLab сделает вам все то, что сделает GitHub. Вот так вот. Веб-интерфейс для доступа к исходникам проектов, визуальное администрирование git, красивые диффы, wiki, issue tracking и еще куча всего.
А еще у этих ребят отличный логотип!
Кому и зачем нужен GitLabНе скрываем, SkyCase попал в первую категорию. Облачные сервисы хороши тем, что «не надо париться». Но за это надо платить. Мы решили, что «мы сами умные», и, один раз напрягшись, создадим систему на века. Тем более, что арендовать виртуальный сервер нынче «непозволительно» дешево.
Системные требования GitLabПреамбула: ниже описывается, как мы установили GitLab v. 6.2.0 на Ubuntu Server Edition v. 13.04.
Официальное руководство не страдает избыточной информацией, так что нам пришлось изрядно постараться самим. Теперь — закатайте рукава!
Если на вашем сервере обнаружен swap раздел достаточно объема, то смело переходите к следующему пункту. На нашем виртуальном сервере swap был отключен. И мы включили.
Если последняя команда выдает ошибку (не найдена команда python2), тогда
Увы, процедура установки GitLab не очень-то проста. Но цель, в данном случае, полностью оправдывает средства! Остается только пожелать терпения и немного усердия вам и вашему системному администратору!
Элемент нумерованного спискаСоздаём репозиторий на гитлабе
Создаём репозиторий на локалке
Кидаем хук Webhook в папку protected/components и в том же файле настраиваем repository name
Подключаем его в Контролере(см. ниже «Подключение в контроллере») и необходимо убедится что он доступен без авторизации, как для гостя
Делаем комит с локалки на гитлаб
Создаём аккаунт cpanel и подключаемся по ssh в него
В этом ssh клонируем репозиторий с гитлаба(предварительно настроив ключи)
Настраиваем ссылку для хука в гитлабе Project » Settings » Web Hooks (пример ссылки http://gevma.idol-it.com/site/webhook )
Всё готово. Дальше делаем как обычно git push и git pull
Существующий проектЭлемент нумерованного спискаСоздаём репозиторий на гитлабе
Кидаем хук Webhook в папку protected/components и в том же файле настраиваем repository name
Подключаем его в Контролере(см. ниже) и необходимо убедится что он доступен без авторизации, как для гостя
Делаем комит с локалки на гитлаб
Подключаемся по ssh к cpanel аккаунту
Удаляем старый репозиторий, клонируем репозиторий с гитлаба(настроив ключи)
Настраиваем ссылку для хука в гитлабе Project » Settings » Web Hooks (пример http://gevma.idol-it.com/site/webhook )
Всё готово. Дальше делаем как обычно git push и git pull
Подключение в контроллере
webhook.txt · Последние изменения: 2015/08/27 04:46 — monkeymafia