Gitlab как пользоваться на русском

GitLab — это онлайн сервис для работы с git репозиториями, у которого есть Open Source версия, которую можно установить и развернуть на своем сервере. Разработчики позиционируют свой сервис как альтернативу GitHub и с этой задачей он полностью справляется. Здесь есть все то же самое, что и на GitHub, плюс бесплатные неограниченные частные репозитории, создание команд, редактирование кода прямо в браузере и многое другое.

В этой статье мы поговорим о том, как пользоваться GitLab для разработки своих проектов. Как создавать репозитории и взаимодействовать с ними. Если вам нужна информация по Git, то лучше смотрите статью как пользоваться git.

Как пользоваться GitLab

1. Создание аккаунта

Зарегистрироваться на GitLab очень просто. Откройте главную страницу GitLab найдите в правой части экрана форму входа и перейдите на вкладку Register. Здесь вам нужно ввести ваше имя, логин, адрес электронной почты, согласится с условиями использования и нажать кнопку Register:

После этого вам на почту придет сообщение со ссылкой для подтверждения аккаунта, перейдите по ней:

Теперь ваш аккаунт подтвержден и вы можете в нём авторизоваться:

После ввода логина и пароля вы попадете на главную страницу профиля. Сейчас здесь страница приветствия, но позже тут будет список ваших репозиториев:

2. Создание репозитория

Чтобы добавить проект GitLab кликните по значку + по центру верхней панели и выберите New Project:

Здесь вам нужно ввести имя репозитория, его описание, а также выбрать уровень доступа:

• Private — доступен только вам;
• Internal — доступен всем зарегистрированным пользователям;
• Public — доступен абсолютно всем.

Ещё вы можете установить галочку напротив Инициализировать репозиторий файлом README, но если вы хотите залить сюда файлы из уже существующего репозитория, делать этого не следует:

После нажатия на кнопку Create repo вы попадаете на страницу репозитория. Здесь GitLab уже предлагает первоначальный набор действий, чтобы проиниализировать ваш репозиторий. Например, вы можете создать здесь файлы или загрузить сюда файлы из вашего компьютера.

4. Загрузка файлов проекта

Давайте создадим новый локальный репозиторий на компьютере и загрузим его содержимое на GitLab. Для этого создайте папку репозитория, например, test-repo и инициализируйте в ней новый репозиторий командой git:

mkdir test-repo && cd test-repo

Затем давайте создадим файл test.txt:

This is test losst repo

И зафиксируем изменения:

git add test.txt
git commit -m "Inital commit"

Дальше нам нужно добавить наш удаленный репозиторий с GitLab к нашему локальному. Для этого выполните:

git remote add origin https://gitlab.com/losst/test-repo.git

Затем отправляем изменения в удаленный репозиторий:

git push origin master

Для отправки данных нужно ввести ваш логин и пароль на GitHub. Теперь, если вы обновите страницу репозитория на GitHub, то увидите там наш файл:

Важно отметить, что если удаленный репозиторий не пуст, то у вас не получиться так сделать. Вам нужно будет сначала скачать удаленный репозиторий, слить локальные изменения с ним, а потом уже отправить всё назад.

5. SSH ключи

Во время загрузки данных репозитория на GitLab нам нужно было ввести логин и пароль на сервере. Чтобы этого избежать можно использовать SSH ключи для авторизации. Сначала вам нужно создать такой ключ. Для этого откройте терминал и выполните:

Введите путь к файлу, куда нужно сохранить ключ, а пароль оставьте пустым. Будут созданы два файла — открытый ключ с расширением .pub и закрытый. Вам нужен открытый. Откройте его в текстовом редакторе и скопируйте его содержимое в буфер обмена:

Далее возвращайтесь к интерфейсу GitLab кликните по иконке профиля и выберите Settings:

Здесь на левой панели найдите пункт SSH Keys. В этом окне найдите поле Key и вставьте туда скопированный ключ. Далее сохраните изменения. Теперь ваш ключ добавлен:

Далее вернитесь в ваш репозиторий, найдите в правом верхнем углу кнопку Clone и кликните по ней. Нас интересует адрес Clone with SSH:

Возвращаемся к нашему локальному репозиторию, удаляем адрес https и добавляем ssh:

git remote remove origin
git remote add origin git@gitlab.com:losst/test-repo.git

Настройка ssh GitLab завершена. Теперь все действия будут выполняться по SSH и у вас не будет необходимости вводить логин и пароль.

6. Ветки репозитория

Разберем использование gitlab для работы с ветками. По умолчанию у репозитория есть только одна ветка — это master. Но для реализации дополнительных функций разработку можно выносить в отдельные ветки. В интерфейсе GitLab ветки отображаются слева. Здесь можно выбрать нужную ветку:

Создать новую ветку можно кликнув по значку плюс и выбрав New branch. Но это не обязательно, так как если вы создадите ветку в git и зальете изменения в репозиторий, то ветка появится там автоматически.

Чтобы изменить ветку по умолчанию откройте Settings -> Repository, а потом просто выберите нужную ветку в разделе Default branch:

6. Слияние веток

Поскольку у нас есть ветки и в них разрабатывается функциональность может возникнуть необходимость перенести её из одной ветки в другую. Для этого используются запросы слияния (Merge request gitlab). Давайте добавим ветку new-feature, а в ней создадим файл new-feature с текстом:

git checkout -b new-feature

New feature with change

git add new-feature.txt
git commit -m "add feature"
git push —set-upstream origin new-feature

Теперь, когда мы перейдем в новую ветку через интерфейс GitLab появится кнопка Create merge request. Нажмите на неё:

Здесь нужно написать описание Merge Request, который вы создаете, выбрать ветку источник и ветку цель. Также можно выбрать пользователя, которому будет оправлено уведомление о созданном запросе:

Далее запрос на слияние нужно одобрить. Вы можете посмотреть изменения нажав кнопку Open IDE или через терминал:

Далее просто нажмите кнопку Merge, если хотите слить ветки. Файлы ветки источника заменят файлы в ветке преемника, поэтому будьте осторожны, чтобы не потерять важные данные.

8. Добавление пользователей

Несмотря на то, что репозитории приватные, возможна работа с gitlab командой. Вы можете добавить к ним неограниченное количество разработчиков. Для этого откройте пункт Settings -> Members. Здесь в поле Select members to invite введите никнеймы или адреса электронной почты пользователей, которых надо пригласить, а в поле Choose a role permission выберите их уровень доступа:

Затем нажмите кнопку Add to project.

9. Удаление проекта

Чтобы удалить проект с Gitlab надо открыть Settings -> General -> Advanced и выбрать Remove Project в самом низу страницы:

После нажатия на кнопку вам нужно будет ввести имя проекта, после чего он будет удален:

Выводы

В этой статье мы кратко разобрали как пользоваться GitLab для разработки программного обеспечения. Это далеко не все возможности GitLab, которые заслуживают внимания, там ещё есть релизы, сообщения об ошибках, инструменты автоматизации и тестирования, удобный редактор кода и многое другое. В общем это полноценная альтернатива для GitHub если тот сервис больше вам не нравится. А что вы предпочитаете, GitHub или GitLab? Напишите в комментариях!

Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза "Hello world." Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

Один ответственный разработчик написал небольшой скрипт, который нужно запускать перед каждой отправкой кода заказчикам. Скрипт нетривиален:

Проблема в том, что в команде десять разработчиков, а человеческий фактор еще никто не отменял.

Неделю назад один новичок забыл запустить скрипт перед отправкой кода, в результате чего трое заказчиков получили поломанные сборки. Хотелось бы в дальнейшем избежать подобного, так что вы решаете положить конец этой проблеме раз и навсегда. К счастью, ваш код уже находится на GitLab, а вы помните про встроенную CI-систему. К тому же, на конференции вы слышали, что CI используется для тестирования.

Запуск первого теста в CI

После пары минут, потраченных на поиск и чтение документации, оказывается, что все что нужно сделать — это добавить две строчки кода в файл .gitlab-ci.yml :

Добавляем, коммитим — и ура! Сборка успешна!

Поменяем во втором файле "world" на "Africa" и посмотрим, что получится:

Сборка неудачна, как и ожидалось.

Итак, у нас теперь есть автоматизированные тесты. GitLab CI будет запускать наш тестовый скрипт при каждом пуше нового кода в репозиторий.

Возможность загрузки результатов сборки

Следующим бизнес-требованием является архивация кода перед отправкой заказчикам. Почему бы не автоматизировать и его?

Все, что для этого нужно сделать — определить еще одну задачу для CI. Назовем ее "package":

В результате появляется вторая вкладка

Однако мы забыли уточнить, что новый файл является артефактом сборки, что позволит его скачивать. Это легко поправить, добавив раздел artifacts :

Проверяем… Все на месте:

Отлично! Однако, осталась одна проблема: задачи выполняются параллельно, а нам не нужно архивировать наше приложение в случаях, когда тест не пройден.

Последовательное выполнение задач

Задача ‘package’ должна выполняться только при успешном прохождении тестов. Определим порядок выполнения задач путем введения стадий ( stages ):

Также не стоит забывать о том, что компиляция (которой в нашем случае является конкатенация файлов) занимает время, поэтому не стоит проводить ее дважды. Введем отдельную стадию для компиляции:

Посмотрим на получившиеся артефакты:

Скачивание файла "compile" нам ни к чему, поэтому ограничим длительность жизни временных артефактов 20 минутами:

Итоговая функциональность конфига впечатляет:

• Есть три последовательных стадии: компиляция, тестирование и архивация приложения.
• Результат стадии компиляции передается на последующие стадии, то есть приложение компилируется только однажды (что ускоряет рабочий процесс).
• Архивированная версия приложения хранится в артефактах сборки для дальнейшего использования.

Какие образы Docker лучше использовать

Прогресс налицо. Однако, несмотря на наши усилия, сборка до сих пор проходит медленно. Взглянем на логи:

Что, простите? Ruby 2.1?

Зачем тут вообще Ruby? А затем, что GitLab.com использует образы Docker для запуска сборок, а по умолчанию для этого используется образ ruby:2.1 . Само собой, в этом образе содержится множество пакетов, которые нам ни к чему. Спросив помощи у гугла, узнаем, что существует образ alpine , который представляет собой практически «голый» образ Linux.

Для того, чтобы использовать этот образ, добавим image: alpine в .gitlab-ci.yml .
Благодаря этому время сборки сокращается почти на три минуты:

А вообще, в свободном доступе находится довольно много разных образов, так что можно без проблем подобрать один для нашего стека. Главное — помнить о том, что лучше подходят образы, не содержащие дополнительной функциональности — такой подход минимизирует время скачивания.

Работа со сложными сценариями

Теперь представим, что у нас появился новый заказчик, который хочет, чтобы вместо .gz архива наше приложение поставлялось в виде образа .iso . Поскольку весь процесс сборки реализован через CI, все, что нам нужно сделать — добавить еще одну задачу. Образы ISO создаются с помощью команды mkisofs. В итоге конфигурационный файл должен выглядеть следующим образом:

Обратите внимание на то, что названия задач не обязательно должны быть одинаковыми. Более того, в таком случае параллельное выполнение задач на одной стадии было бы невозможным. Так что относитесь к одинаковым названиям задач и стадий как к совпадению.

А тем временем сборка не удалась:

Проблема в том, что конманда mkisofs не входит в состав образа alpine , так что нужно установить ее отдельно.

Установка дполнительного ПО

На сайте Alpine Linux указано, что mkisofs входит в состав пакетов xorriso и cdrkit . Для установки пакета нужно выполнить следующие команды:

Все это — тоже валидные команды CI. Полный список команд в разделе script должен выглядеть следующим образом:

С другой стороны, семантически более корректно выполнять команды, ответственные за установку пакетов до раздела script , а именно в разделе before_script . При размещении этого раздела в верхнем уровне файла конфигурации, его команды будут выполнены раньше всех задач. Однако в нашем случае достаточно выполнить before_script раньше одной определенной задачи.

Итоговая версия .gitlab-ci.yml :

А ведь мы только что создали конвейер! У нас есть три последовательные стадии, при этом задачи pack-gz и pack-iso стадии package выполняются параллельно:

Подводя итоги

В этой статье приведены далеко не все возможности GitLab CI, однако пока что остановимся на этом. Надеемся вам понравился этот небольшой рассказ. Приведенные в нем примеры были намеренно тривиальными — это было сделано для того, чтобы наглядно показать принципы работы CI не отвлекаясь на незнакомые технологии. Давайте подытожим изученное:

1. Для того, чтобы передать выполнение определенной работы в GitLab CI, нужно определить одну или более задач в .gitlab-ci.yml .
2. Задачам должны быть присвоены названия, советуем делать их осмысленными, чтобы потом самим не запутаться.
3. В каждой задаче содержится набор правил и инструкций для GitLab CI, определяющийся ключевыми словами.
4. Задачи могут выполняться последовательно, параллельно, либо вы можете задать свой собственный порядок выполнения, создав конвейер.
5. Существует возможность передавать файлы между заданиями и сохранять их как артефакты сборки для последующего скачивания через интерфейс.

В последнем разделе этой статьи приведен более формализованный список терминов и ключевых слов, использованных в данном примере, а также ссылки на подробные описания функциональности GitLab CI.

Описания ключевых слов и ссылки на документацию

Ключевое слово/термин	Описание
.gitlab-ci.yml	Конфигурационный файл, в котором содержатся все определения сборки проекта
script	Определяет исполняемый shell-скрипт
before_script	Определяет команды, которые выполняются перед всеми заданиями
image	Определяет используемый Docker-образ
stage	Определяет стадию конвейера ( test по умолчанию)
artifacts	Определяет список артефактов сборки
artifacts:expire_in	Используется для удаления загруженных артефактов по истечению определенного промежутка времени
pipeline	Конвейер — набор сборок, которые выполняются стадиями

Также обратите внимание на другие примеры работы с GitLab CI:

Похожие публикации

• 3 января 2017 в 10:37

Вышел GitLab 8.15

GitLab CI: Учимся деплоить

GitLab Container Registry

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 17

compile:
stage: compile
script: cat file1.txt file2.txt > compiled.txt
artifacts:
paths:
— compiled.txt

А для чего указывать артефакт в задаче compile? Файл compiled.txt понятно, он нам будет нужен в следующих задачах. А зачем его описывать как артефакт?

artifacts используется и для передачи файлов между stages, и для попадания в downloadable artifacts. Возможно это поменятся, но пока так.

А что значит «для передачи файлов между stages»?

В следующих стадиях/задачах используется имя файла compiled.txt. Я так понимаю, это тот самый файл compiled.txt, который создался в задаче compile. Вот просто создался он в задаче compile и лежит себе, а в следующих задачах мы к нему обращаемся.

Без указания артефакта мы не сможем обратиться в нему в следующей задаче? Он будет удален по окончанию задачи compile? А указание артефакта это типа «поставить галочку, что этот файл удалять не надо»?

Подскажите, можно ли иметь единый .gitlab-ci.yml для всех веток?

На стадии его написания многократно приходится синхронизировать его между ветками.

И еще вопрос, можно как-то динамически формировать имя артефакта?
У меня после сборки получается файл package-$-$.el7.centos.$.rpm при чем переменные вычисляются в процессе сборки.

Функционала меньше, чем в Jenkins (это нормально, нужно учитывать):
— нет постоянных ссылок на скачивание последних артефактов (latest, а не номер билда; удобно для скриптов бутстрапа, например)
— вроде бы в последних версиях ручной запуск появился, но нет параметризированного запуска (может и не нужно, можно тот же список серверов забить в файл отдельными ручными работами, но нужно учитывать при проектировании)
— нет работ не привязанных к ветке/репозитарию (из-за этого придется для некоторых вещей сохранить Jenkins)
— нотификации (типа интеграции со слаком) идут вне файла настройки ci

Текущие минусы:
— долго промучился, но команды сборки докера в докере не заработали (ни docker in docker, который не предназначен для систем CI и постоянно в документации Gitlab CI упоминается; ни пробрасывание сокета докера), использую отдельный shell runner для этого.
— кеширует только после успешного завершения работы (например, пока настраиваешь работу каждый раз качает плагины maven)
— медленно (пофайлово?) сохраняет кеш
— нет способа через UI сбросить кеш и посмотреть какие кеши есть. все-таки кеши время от времени приходится сбрасывать
— по ощущениям собирает медленней Jenkins, относительно долго (секунд 15) запускается любая докер-работа с одной командой echo
— нет готового рецепта для Java/Maven, что-то настроил, но еще не все

В целом, удобно, что интегрировано, но еще сыро.

Можно ли указать в качестве зависимости другой проект, что бы он тоже подтянулся для сборки?
И можно ли шарить артефакты между проектами?

Такой вопрос, стокнулся с казалось бы тривиальной задачей в Jenkins — необходимо запускать job при попадании нового тега (с определенным именем, например build_[0-9] <6,10>). Казалось бы все должно быть очень просто, а на деле оказалось что нет. Например у нас есть следующая история

Так вот в Jenkins cборка будет запущена только для head, для остальных 3х тегов она будет игнорироваться. Можно ли в gitlab ci обеспечить сборку в любом "направлении", чтобы при командах

я получил в итоге 4 билда?

Ничего из описанного не работает:( Вообще не запускается, появляется значок «pending» и всё.

Я так понимаю, нужен некий раннер. Какой минимум нужно сделать, чтобы запустить хотя бы самый простейший тест?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Blog about IT, Me, My travels, vacations, etc…

Добрый день! Данная статья представляет собой краткий мануал как пользоваться Git в производственной среде. В прошлой статье я уже упоминал про развертывание Gitlab сервера внутри компании, считайте эту статью — продолжением.

Откуда черпать информацию:

Поставить Git можно на любую ОС — консольные и графические клиенты есть под любую операционку.
Мое имхо — использование графических клиентов излишне, мне хватает консольного клиента, тем более в сети большинство примеров про него. Но если что — клиенты встроены во все популярные IDE.

Основные команды

Что надо обязательно знать и уметь использовать (я привожу их в случайном порядке):

Подготовка к работе

Итак, дорогой друг, ты решил попробовать эту странную штуку под названием Git, хотя ни разу ей не пользовался — погнали!

1. Сгенерируй себе ssh ключ.
Я понятия не имею какой ОС ты пользуешься так что загугли как это сделать (да, я даже облегчил тебе задачу). Я использую Linux, у меня он уже есть.

2. Настрой свой git клиент. Для этого есть опции config. Мне хватает 4-х:

Кстати, когда ты пользуешься опцией global — ты задаешь настройку для клиента глобально (кеп), а если ты введешь такие же команды в конкретном репозитории — ты настроишь параметры только для него.

3. Иди в Gitlab через веб интерфейс (либо публичный, либо свой, если разворачивали) и там заходи со своей учеткой. И да если ты пользуешься своим Gitlab серверов, как это было в прошлой статье, не забудь выбрать вкладку LDAP:

Настройка учетки в Gitlab

Надеюсь ты смог залогиниться.
Далее идем в настройки профиля (https://гит-сервер/profile):

Там настраиваем себе язык, цвет темы, цвет редактора, аватарку, черта лысого — развлекайся.
Главное- потом не забудь зайти в пункт SSH ключи (https://гит-сервер/profile/keys) и там добавить хотя бы 1 (но только публичную часть):

(если что, я тут сократил ключ чтобы весь не вставлять)

/ . ssh / test — key . pub

Плюс советую поиграться с настройкой тем и редактора: https://гит-сервер/profile/preferences

И настроить дефолтный дашборд:

Создание репозитория

Давай рассмотрим создание репозитория на примере репы для бекап-скриптов. Для этого я сделал отдельный неймспейс/группу OPS (Operations)

и теперь создадим тут сначала подгруппу (New Subgroup) а потом проект (New Project). Проект это и есть репозиторий. А группу я хочу сделать для большей гранулированности — чтобы скрипты для бекапов были в подгруппе «backups». Ну так выглядит симпатичней и навигация проще имхо.

Итак, мы получаем страничку пустого проекта (сиречь репозитория):

где нам не двусмысленно подсказывают как мы можем начать работу. Такая подсказка будет появляться у вас на экране КАЖДЫЙ раз при создании пустого проекта и висеть там ДО ТЕХ ПОР пока вы хоть 1 файл в проект не зальете. Так что не надо себе сохранять как памятку:

Пример работы с репозиторием

Подготовка

Итак, для примера у меня есть папка test в которой лежат пара скриптов для бекапа файлов — я хочу запихнуть их в этот репозиторий, инициировав его. Итак, что на входе:

Я не хочу чтобы в репозиторий попадали всякие мусорные файлы, как например скрытая папка «.directory», как тут. Для этого я делаю файл «.gitignore» в который вношу имена и маски имен объектов (файлов и каталогов) которые должны игнорироваться git-ом:

Инициализация и первый коммит

Теперь воспользуемся инструкцией из второго примера на нашей страничке пустого проекта «Existing folder»:

Теперь разберем по пунктам что я сделал:

Смотрим результат

Итак, возвращаемся в Web интерфейс гитлаба и что мы там видим:

Создание веток и слияние

В гите есть понятие веток — это одна из основополагающих концепций и вам ПРИДЕТСЯ ее узнать и полюбить.

Основная идея такова — есть главная ветка, которую обычно зовут «мастер» и ряд других. Например «develop», «staging» и пр. В ряде случаев для имени ветки выбирается имя фичи или изменения над которым в ней работают. Когда разработчик хочет внести изменение в код — он должен «ответвиться» от мастера, поработать, внести свои наработки в свою ветку репозитория, протестировать их и только убедившись что все хорошо (хорошей практикой является демонстрация этих наработок и их тестирования коллегам) — «влить» изменения из своей ветки в мастер.

Такой подход зовется Git Flow и выглядит примерно вот так:

Его мы сейчас и попробуем реализовать (Правда в одно лицо, но для групповой работы схема будет примерно такой же). Мы забыли добавить очень важный файл, который должен являться неизменным атрибутом каждого репозитория — файл README. Как и все git хостинги, Gitlab ищет в каталоге репозитория этот файл и если находит- показывает его содержимое на главной странице репозитория сразу под списком файлов. Gitlab понимаем и умеет рендерить разметку markdown, правда с некоторыми своими условностями, поэтому советую почитать их документацию.

Если Вам лень учить синтаксис или ставить локальный редактор makrdown, или искать плагин к свой ide, воспользуйтесь вот этим сервисом — stackedit.io

Добавим простой файл Readme в котором опишем содержимое проекта: