Pipeline - только зеленые тесты?

#1

Добрый вечер, коллеги.

Вопрос по jenkins pipeline.

По курсу “Разработка по промышленным стандартам. ч.2.” я сделал сборочную линию.
Но выходит, что отчеты по прошедшим тестам я смогу увидеть, когда они сформируются. А сформируются они, если шаг “проверка поведения” будет пройден.
А если какой-то сценарий упадет с ошибкой, то упадет шаг и вся сборочная линия, только в отчете последнего прогона я не увижу. Да и вообще в отчете Аллюр в Jenkins я всегда буду видеть только зеленые тесты.

Чего хотелось бы добиться:

  1. Чтобы шаг “Проверка поведения” не падал и не валил всю сборку, если тесты красные.
    в логах пишет так:

ОШИБКА - Ошибка:{Модуль C:\Program Files (x86)\OneScript\lib\vanessa-runner\src\Классы\КомандаТестированиеПоведения.os / Ошибка в строке: 187 / Результат работы не равен 0 Информации об ошибке нет}

это про файл VBStatus.log, в котором 0 или 1 пишет bddRunner ?
Это можно отключить или повлиять на это?
2. Если п.1 возможен, тогда после шага “Публикация результатов” делать проверку на “0” в файле VBStatus.log и валить сборку уже здесь.

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

Подскажите, это возможно? и как?

#2

Все гораздо проще. В pipeline для этого есть специальный блок. Используй его.

post {
        // Исполняется всегда, вне зависимости от результата сборки
        always {
        }

        // Исполняется в случае ошибки сборки
        failure { 
        }    
    
        // Исполняется в случае успешного выполнения сборки
        success {
        } 
}
#3

always green pipeline - это одна из неназванных проблем, которую я специально оставил в видео “на подумать”. На форуме этот вопрос поднимался уже. В целом решений несколько - перенести публикацию в секцию post, как писал Руслан, либо оборачивать шаги в try-catch/catchError

#4

Сделал через post, но теперь не видно стадию “публикация результатов”, т.к ее шаги теперь в разделе always.

#5

bat “”"
chcp 65001
call …
exit /b 0
“”"
Можно явно переназначать результат выполнения команды. Т.е. делать шаг где тесты прогоняются всегда успешным. Потом публиковать результаты отдельным шагом, если так надо. Потом по флагу-семафору, в который можно писать результаты тестирования уже делать шаг, в котором падать или нет.

#6

Переделал так.
Спасибо за советы ))

#7

Мне всегда было интересно, зачем рекомендация try/catch?
Ведь в теории выполняются сначала Unit, потом BDD.
У меня, например, UNIT-BDD-UI(большой пользовательский сценарий=демонстрация клиенту).
И если где-то упало на предыдущем шаге - дальше гнать тесты не имеет смысла.

Если у меня не работают UNIT, то оооочень вероятно что и BDD упадут.

#8

а смотря, что за стейджи и какое покрытие юнитами/БДДой (с покрытием вообще пока всё грустно и нипанятна)
т.е. если задача при первой же ошибке всё стопнуть и чинить её, то тогда надо падать сразу
а если задача собрать все возможные ошибки по всем имеющимся тестам (и юнитам, и бдд), то вот и прогоняется всё полностью, чтобы полный отчет собрать

#9

Все верно, я с этой мысли и начал )))

#10

Ну главное не привыкать. Когда нормальное покрытие получишь - последовательно выполнять шаги

#11

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

#12

Возможно это только моя заморочка. Но развернуть базу для юнитов у меня сейчас занимает 5 секунд. И выполнить юнит-тесты - 4 минуты. Для UI использую типовые, разворачивая через dt. И только поднятие базы занимает 4-8 минут. Таким образом, если упали Юнит - мне нет смысла гнать UI - потому что они точно упадут. И я сэкономлю на развертке базы и выполнении UI тестов

#13

Да, оба подхода возможны.
Поэтому и нет жесткой рекомендации.
Есть и полные сборки, бывают и “короткие” сборки