Как Gitlab-CI и OneScript могут отсортировать массив (Часть 1)

Часть 1 (вы здесь)

Часть 2

В этом году я первый раз был на 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, потрогаем условия и зависимости