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

12.12.21

Разработка - DevOps и автоматизация разработки

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

Gitlab Gitlab-CI devops CI/CD

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    6729    26    0    

23

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9148    78    4    

110

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6592    10    0    

9

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019    24217    54    VPanin56    26    

26

1С, СППР и Архитектура как код

DevOps и автоматизация разработки Бесплатно (free)

Можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

01.02.2024    2468    roman72    9    

7

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    2783    kamisov    17    

57

Infrastructure as code: кнопка «Сделать всё», или Упаковываем наше окружение в 5 кБ текста

DevOps и автоматизация разработки Бесплатно (free)

Когда под каждый проект нужно развернуть отдельный стенд разработки и сборочную линию для его обслуживания, велик риск влияния человеческого фактора. О том, как зафиксировать инженерный опыт в скриптах и унифицировать необходимые настройки для автоматизированного разворачивания инфраструктуры с помощью Terraform и Ansible, пойдет речь в статье.

01.11.2023    1325    Libelle    5    

13

Обработка для подготовки файла настройки дымовых тестов измененных объектов конфигурации

DevOps и автоматизация разработки Тестирование QA Россия Абонемент ($m)

В статье приведен пример обработки, которая на основании измененных файлов git-репозитория готовит специальный файл настройки xUnitParams.json для последующего выполнения дымовых тестов (xUnitFor1C/add) только для измененных объектов конфигурации

1 стартмани

09.10.2023    710    5    ICL-Soft    0    

3
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. lunjio 66 18.11.21 13:45 Сейчас в теме
С приходом в 1С EDT мы получили git. С git-ом пришел и gitlab, а он уже дает инструменты по CI. Что такое CI? Ну все же знают, как обычно просят обновить прод? Желательно ночью? Желательно проверив на копии, что ничего не сломаем? Ну так вот: CI – это личный помощник, который все сделает сам. Надо только правильно его попросить...

Git самый удобный контроль версий, спору нет. CI - continuos integrtion, сам протестирует, главное попросить ? звучит заманчиво конечно ) В целом спасибо за статью, но вот автоматическое тестирование и заливание средствами непрерывной интергации в 1С, для меня до сих пор что-то как Hyper Loop, теоретически все круто вроде, но до сих пор не ясно как сделать так, чтобы люди в лепешку не смялись когда торможение будет происходить на такой скорости экстренное )
2. SaschaG 193 18.11.21 13:51 Сейчас в теме
(1) Спасибо. Ну начинать не спеша. Главное запустить, преодолеть порог вхождения, а там добавишь сборку, добавишь тесты и уже втянулся и хочешь еще больше автоматизировать свою работу.
Iscarimet; pavlov_dv; artbear; +3 Ответить
3. lunjio 66 18.11.21 13:58 Сейчас в теме
(2) Да, но вот как допустим подготовить тесты под изменение формы документа, где нужно протестировать под разными пользователями, с разными правами и т.п ? Для меня есть другие языки программировани, на которых очень понятные и расширенные инструменты тестирования. Касательно 1С можно тестами процедуры проверить, а вот касательно интерфейса, для меня тут кажется из двух зол меньшее надо выбирать, руками тестировать. Почему ? Да потому что нет нормальных инструментов для написания тестов, либо запись мышкой предлагают, в то время как в Xamarin у каждого элемента есть AutomationID где ты из кода можешь какой угодно сценарий прописать.
4. SaschaG 193 18.11.21 14:02 Сейчас в теме
(3) ну мы сценарные тесты через ванессу делаем - справляется отлично. Да, нужен человек с компетенциями и я сталкивался, когда на этом все глохло, но выигрыш от автотестов чувствуется. Ну невозможно руками перед каждым релизом все прокливать. А так смотришь только упавшие сценарии и отправляешь или QA тесты править, или разработчику чинить
5. lunjio 66 18.11.21 14:06 Сейчас в теме
(4) А вы считали затраты по тестам и ручного тестирования относительно времени ? Может гораздо выгоднее руками протестировать после того как доработал, чем писать тесты, еще под каждую доработку и тесты подгонять.
8. SaschaG 193 18.11.21 17:48 Сейчас в теме
(5) тестами имеет покрывать как минимум основные бизнес-процессы и сценарии пользователей. Никогда не знаешь где всплывет "это маленькое изменение". Приемочное тестирование при сдаче задачи мы проводим руками, но если при поломке этого функционала пользователи работать не смогут, то имеет смысл покрыть его тестами, чтобы случайно не сломать через 2-3-4 релиза, когда все все забудут. Да, на поддержание тестов тоже нужно тратить время, но тут вопрос в какую сумму компания оценивает час простоя.
buganov; pavlov_dv; +2 Ответить
6. aximo 2027 18.11.21 14:30 Сейчас в теме
Вот у меня появилась такое предположение сейчас, что EDT создавался для того (в том числе), чтобы перетянуть в отрасль 1с программистов С, С++, PHP-шников и прочих.

Вот наняли как-то мы "чистых" программистов на написание бизнес приложения - а они мне и готовят спустя некоторое время - мы не можем найти ставку 6% (налог на прибыль) в ставках НДС на товары. В результате имеем, что имеем.
9. dhurricane 18.11.21 17:50 Сейчас в теме
(6)
Вот у меня появилась такое предположение сейчас, что EDT создавался для того (в том числе), чтобы перетянуть в отрасль 1с программистов С, С++, PHP-шников и прочих.
Точно нет. :-)

Вот наняли как-то мы "чистых" программистов на написание бизнес приложения - а они мне и готовят спустя некоторое время - мы не можем найти ставку 6% (налог на прибыль) в ставках НДС на товары. В результате имеем, что имеем.
Собственно, а зачем Вы нанимали "чистых" программистов не под "чисто-программистские" задачи?
7. aximo 2027 18.11.21 14:37 Сейчас в теме
но из-за уважения к труду вложенного в написание статьи - плюс
Оставьте свое сообщение