Часть 1 (вы здесь)
В этом году я первый раз был на Infostart Event 2021 и сразу докладчиком. Презентация у меня была про Gitlab-CI, но больше обзорная про то, что "в Gitlab можно сделать вот это вот все, а как это сделать можно узнать в документации". Чтобы рассказать про все настройки, 30 минут было бы мало. К счастью, в формате статьи время у меня не ограничено. Сразу скажу: это учебный (и в некотором смысле даже шуточный) пример, он сделан не для того, чтобы дать готовые скрипты, а чтобы, повторив эти шаги, вы поняли, какие инструменты нам дает Gitlab-CI. И это на примере, для которого даже не нужно будет ставить платформу.
И должен сказать пару слов на тему "зачем нам CI": сейчас, с приходом в 1С EDT, мы получили git. Использовать его удобно, намного лучше, чем хранилище. С git-ом пришел и gitlab, а он уже дает инструменты по CI. Что такое CI? Ну все же знают, как обычно просят обновить прод? Желательно ночью? Желательно проверив на копии, что ничего не сломаем? Ну так вот: CI – это личный помощник, который возьмет ваш проект EDT из gitlab и сам протестирует и зальет его на прод. Надо только правильно его попросить...
Часть 1: Наш первый проект
Предварительно нам надо будет установить то, с чем мы будем работать:
Git (для версионирования) – https://git-scm.com/
Тут стоит после установки указать некоторые настройки. Для этого откроем Git Bash (или CMD) и выполним три команды:
Первыми двумя мы устанавливаем имя и почту, которые отображаются в коммитах, третий — снимает ограничение на длину путей для git в windows (по умолчанию 260 символов, но git поддерживает до 4096).
OneScript (для выполнения скриптов) – https://oscript.io/
После установки надо в консоли выполнить "opm install --all" - данная команда установит все пакеты (ну или можете по потребности устанавливать что вам нужно).
VSCode (для написания скриптов) - https://code.visualstudio.com/
После установки необходимо перейти в плагины и скачать Language 1C (BSL)
Теперь перейдем на https://gitlab.com/ , далее нажимаем Login в верхнем правом углу и, если аккаунта еще нет, то нажимаем "Register now"
После входа под своим пользователем мы переходим на https://gitlab.com/dashboard/projects и нажимаем "New project" → "Create blank project". Заполняем все поля по образцу. Здесь я указал Visibility level как "Public" чтобы при чтении статьи можно было сверяться с моим репозиторием, но для себя можете указать "Private"
И нажимаем "Create project". После этого Gitlab нам дает шаблоны того, что нам стоит сделать, открыв консоль:
"Git global setup" мы выполнили еще при установке Git, а вот "Create a new repository" нам как раз и нужен, ведь у нас еще нет какого-то кода. В папке, где будет лежать наш проект, через контекстное меню в проводнике выбираем "Git Bash Here" и пока вводим только первую строку, в моем случае это "git clone https://gitlab.com/ffSaschaGff/possum_app.git", после этого у нас появится папка, в которой, если у вас отображаются скрытые папки, вы увидите подпапку .git
Давайте теперь откроем наш проект в VS Code – в папке с ".git" в контекстном меню выбрать "Открыть с помощью Code" и создадим файл .gitlab-ci.yml
Именно в этом файле мы будем указывать, что, когда и где должен делать наш CI. Описание структуры файла можно найти https://docs.gitlab.com/ee/ci/yaml/ , но мы пока не будем спешить. Итак, какие stages (этапы сборки) будут у нашего проекта? Ну давайте начнем с тестирования и сборки:
stages:
- test
- build
И определим для каждого Stage свою работу (Job), в каждой из которых будет вызываться свой скрипт:
test:
stage: test
script: oscript ./ci/scripts/test.os
build:
stage: build
script: oscript ./ci/scripts/build.os
В итоге получим такой файл (отступы важны - они определяют структуру):
Осталось создать файлы ci/scripts/test.os и ci/scripts/build.os, пока что пусть они просто выводят сообщения о том, что было бы сделано:
Что же, давайте отправим наши изменения в удаленный репозиторий! Переходим на "Source control" → нажимаем "Stage All Changes" → вводим сообщение первого коммита → жмем на галку, чтобы создать коммит:
Теперь осталось отправить коммит в удаленный репозиторий: нажимаем на меню (…) и выбираем Push
Теперь переходим в гитлаб на страницу нашего проекта и видим, что изменения пришли, файлы появились. Давайте же перейдем на вкладку CI и посмотрим, как выполнился наш пайплайн:
И мы видим, что он завершился с ошибкой:
Давайте нажмем на первый красный круг в столбце Stages и откроем Job "test". Мы увидим, что ошибка в том, что не была найдена команда oscript, а сама работа была исполнена на каком-то Runner: #44028 (fa6cab46) shared-runners-manager-3.gitlab.com.
Скрипты, которые мы пишем для CI, выполняются не где-то там на сервере Gitlab, а на раннерах — удаленных компьютерах, где запущен gitlab-runner. Давайте перейдем в настройки → CI/CD
Здесь нам надо дойти до раздела "Runners" и нажать "Expand", после чего отключить "Shared runner", которые нам дает gitlab, а дальше развернем и зарегистрируем свой:
В папке рядом с проектом создадим еще одну и назовем "runner", дальше с https://docs.gitlab.com/runner/install/windows.html качаем из п.2 файл нужной разрядности и сохраняем в папку назвав "gitlab-runner.exe". Далее открываем консоль как администратор и переходим в папку c раннером "cd ваш_путь_к_папке", и выполняем команду "gitlab-runner.exe register". После этого он попросить сначала ввести:
Адрес сервера Gitlab — https://gitlab.com/
Токен — был на странице с настройками на предыдущем скриншоте
Имя раннера — у меня lockal-runner
Теги через запятую – пока нажмем Enter, к ним мы вернемся позже
И исполнитель — shell
Если все сделано правильно, то мы увидим сообщение, что раннер был зарегистрирован:
Запускать скрипты мы будем с использованием powershell, так что теперь откроем папку (консоль не закрываем, она еще понадобится) с раннером и видим в ней файл config.toml. Откроем его любым редактором и заменим shell = "pwsh" на shell = "powershell"
Теперь запустим его как службу, выполнив в консоли (вы же ее не зарыли?) "gitlab-runner.exe install" и "gitlab-runner.exe start". После этого, если мы снова вернемся в настройки CI/CD на Gitlab, то мы увидим наш раннер в списке:
Давайте перейдем список сборок (Pipelines) и перезапустим тот, который до этого завершился с ошибкой:
И, если все было сделано правильно, то вы увидите, что pipeline завершился успешно и и в каждой из работ вывелось сообщение в консоль:
Хмммм, но мы же не это вводили. Видимо проблемы с кодировкой. Надо всего лишь перед каждым скриптом выполнять 2 команды:
[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding("utf-8")
[Console]::InputEncoding = [System.Text.Encoding]::GetEncoding("utf-8")
Но дописывать их в каждый Job руками не очень хорошо. Вот бы была у нас возможность указать какое-то поведение по умолчанию? Да, мы можем так сделать. В секции default мы можем определить то, что будет добавляться к каждому Job-у, если это в нем не переопределено. Если мы туда добавим команды в секцию before_script, то они будут выполнятся перед каждой Job. Остается только закоммитить изменения и сделать push:
Перейдем в Gitlab и посмотрим пайплайны. Когда новый появится и выполнится, то мы увидим, что текст в Job-ах стал читаем:
Сообщения — это конечно хорошо, но давайте что-то соберем. Только что именно? Ну значит пришло время написать наше приложение. Создадим в корне проекта папку src. В ней создадим файл possum.os, а так же папку src/Модули с файлом Сортировка.os
Как вы уже поняли, наше приложение-опоссум будет что-то сортировать. Для начала в possum.os напишем:
#Использовать cmdline
#Использовать "Модули/.."
Процедура Инициализировать()
Параметры = ПолучитьПараметры();
Если Параметры["Команда"] = "sort" Тогда
МассивЧисел = ПолучитьМассивЧисел(Параметры["Значение"]);
Результат = Сортировка.Отсортировать(МассивЧисел);
Сообщить(Результат);
Иначе
ВызватьИсключение "хссссс";
КонецЕсли;
КонецПроцедуры
Функция ПолучитьМассивЧисел(ИсходнаяСтрока)
ТипЧисло = Новый ОписаниеТипов("Число");
МассивСтрок = СтрРазделить(ИсходнаяСтрока, ",");
МассивЧисел = Новый Массив;
Для каждого ЧислоСтрокой Из МассивСтрок Цикл
МассивЧисел.Добавить(ТипЧисло.ПривестиЗначение(ЧислоСтрокой));
КонецЦикла;
Возврат МассивЧисел;
КонецФункции
Функция ПолучитьПараметры()
Парсер = Новый ПарсерАргументовКоманднойСтроки();
Парсер.ДобавитьПараметр("Команда");
Парсер.ДобавитьПараметр("Значение");
Параметры = Парсер.Разобрать(АргументыКоманднойСтроки);
Возврат Параметры;
КонецФункции
Инициализировать();
А в Сортировка.os реализуем опоссумовую сортировку: на каждом шаге мы даем нашему пушистому зверьку переставить 2 элемента массива. Если после этого массив отсортирован, то значит опоссум справился. Если же нет, то он просто пока не закончил и надо еще немного подождать.
Функция Отсортировать(СортируемыйМассив) Экспорт
ГСЧ = Новый ГенераторСлучайныхЧисел(42);
Пока Не МассивОтсортирован(СортируемыйМассив) Цикл
Позиция1 = ГСЧ.СлучайноеЧисло(0, СортируемыйМассив.Количество());
Позиция2 = ГСЧ.СлучайноеЧисло(0, СортируемыйМассив.Количество());
Буфер = СортируемыйМассив[Позиция1];
СортируемыйМассив[Позиция1] = СортируемыйМассив[Позиция2];
СортируемыйМассив[Позиция2] = Буфер;
КонецЦикла;
Возврат СортируемыйМассив;
КонецФункции
Функция МассивОтсортирован(ПроверяемыйМассив)
Для Н = 0 По ПроверяемыйМассив.Количество() - 2 Цикл
Если ПроверяемыйМассив[Н] > ПроверяемыйМассив[Н + 1] Тогда
Возврат Ложь;
КонецЕсли;
КонецЦикла;
Возврат Истина;
КонецФункции
Попробуем запустить, чтобы проверить, что сортировка замечательно работает: Terminal → New Terminal и выполним скрипт
Теперь давайте изменим скрипт build.os:
#Использовать 1commands
Команда = Новый Команда;
Команда.УстановитьСтрокуЗапуска("oscript -make ./src/possum.os ./possum.exe");
Команда.Исполнить();
Сообщить("Я собрался!");
А в .gitlab-ci.yml в Job build:
build:
stage: build
script: oscript ./ci/scripts/build.os
artifacts:
paths:
- ./possum.exe
expire_in: 1 week
Что значит этот artifacts? Мы говорим, что в корне репозитория может быть файл possum.exe и если он есть, то мы его сохраняем, он будет доступен для скачивания из pipeline и в последующих Job-ах. Так же мы должны указать сколько он будет храниться — 1 неделю. Давайте закоммитим изменения и отправим их в удаленный репозиторий:
Давайте откроем Gitlab и посмотрим последний pipeline:
Если мы все сделали правильно, то мы сможем скачать архив с собранным possum.exe
Если вдруг что-то не вышло, то вы можете скопировать себе версию проекта в состоянии на конец этой статьи, выполнив 2 команды в какой-либо пустой папке:
git clone https://gitlab.com/ffSaschaGff/possum_app.git .
git checkout ca1712c711c0626df5079ae80939325d05b158ff
На этом первая часть закончена. Если отзывы будут положительными, то в следующей серии мы потрогаем ветки, посмотрим, как получить в CI результаты тестов, что такое переменные CI, потрогаем условия и зависимости
