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

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

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

В наличии

С приходом в 1С EDT мы получили git. С git-ом пришел и gitlab, а он уже дает инструменты по CI. Что такое CI? Ну все же знают, как обычно просят обновить прод? Желательно ночью? Желательно проверив на копии, что ничего не сломаем? Ну так вот: CI – это личный помощник, который все сделает сам. Надо только правильно его попросить…

Категория:

Описание

Часть 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, потрогаем условия и зависимости

has been added to your cart:
Оформление заказа