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

запускать постоянно тесты это немного странно, никогда такого не видел)

но! даже если мы по-прежнему хотим это делать, то я бы сделал вызов маленькой джобы по крону
вызвали джобу => запустили докер (или лучше даже без него, чтобы побыстрее) => прогнали тесты => зарепортили результат и сделали с ним (результатом), что хотим
плюсы:
- не надо решать проблему "упала ли джоба или упали тесты", процесс отработал и завершился, есть конкретный результат
UPD: Ладно, возможно и надо будет, соврал. Тогда, наверно, сделать запуск почаще и отслеживать несколько падений. Типа 1 раз - ок, терпим, 2/3/сколько_нужно раз - не ок, тревога.

- крон не подведёт 🙂

Я так и делаю. Ранится много джоб по кронам с разными интервалами
И как ты написал, результат нужно анализировать, особенно если он красный )

И да, все может подвести. Если крон надежный, то приемтабл нода - так себе

> Если крон надежный, то приемтабл нода - так себе

what?

Это имел ввиду
https://cloud.google.com/kubernetes-engine/docs/how-to/preemptible-vms

Или в чем я ошибся?

ребята, привет
нужно мнение экспертов )

есть у меня мониторинговые тесты - ранятся на проде с определенной периодичностью (например, 5 минут) и проверяют работоспособность продукта

вопрос касательно инфрастуктуры тестов – обязательно ли, чтобы джоба (с тестами) завершалась с ошибкой, когда падает тест?

приведу несколько аргументов от себя
- конечно, в стандартном CI/CD процессе упавшая джоба и стоп пайплайна - это маст хев. но в данном случае (помним, что тесты мониторинговые) стоп пайплайна нам не нужен, нам нужно только оповещение что именно упало
- назревает вывод, что раз мы должны знать, что есть падение, то и джобу нужно завершать с еррором. но можно же ошибку слать руками в момент завершения всех тестов но еще, так сказать, не выходя из контейнера. а сам контейнер завершать успешно, тестовый прогон ведь был выполнен, хоть и тест упал
- возможно, у вас назреет еще один вопрос - почему я задаюсь этим вопросом, не пусть себе завершается джоба с эррором, ведь в ней упавший тест. но! как тогда нам различать падение джобы произошло из-за ошибок ифнрастуктуры (не поднялся контейнер, не хватило памяти и т.д.) или упал тест? ну.. можно через еррор коды, но имхо, это геморно. или нет?
- скорее, в CI/CD системах (Jenkins, Gitlab, Github) упавшие джобы хендлить удобно и легко настроить алерты. но мои ранятся в GCP. и здесь падение джобы рассматривается как что-то аномальное и это вызывает некие проблемы с конфигурацией алертов. (например, мы будем получать алерт, пока не удалим упавшую джобу, даже если после нее уже была успешная)

поделитесь вашим опытом. буду рад комментариям 💪

На примере AWS: https://aws.amazon.com/blogs/aws/new-use-cloudwatch-synthetics-to-monitor-sites-api-endpoints-web-workflows-and-more/

Я так и делаю. Ранится много джоб по кронам с разными интервалами
И как ты написал, результат нужно анализировать, особенно если он красный )

И да, все может подвести. Если крон надежный, то приемтабл нода - так себе

Я по-прежнему считаю, что это не через тесты решать надо. Логи фронта тоже можно собирать и тоже грамотно алертить.

Почитаю, спасибо
А в этой штуке браузер можно ранить? (Для UI тестов)

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

ребята, привет
нужно мнение экспертов )

есть у меня мониторинговые тесты - ранятся на проде с определенной периодичностью (например, 5 минут) и проверяют работоспособность продукта

вопрос касательно инфрастуктуры тестов – обязательно ли, чтобы джоба (с тестами) завершалась с ошибкой, когда падает тест?

приведу несколько аргументов от себя
- конечно, в стандартном CI/CD процессе упавшая джоба и стоп пайплайна - это маст хев. но в данном случае (помним, что тесты мониторинговые) стоп пайплайна нам не нужен, нам нужно только оповещение что именно упало
- назревает вывод, что раз мы должны знать, что есть падение, то и джобу нужно завершать с еррором. но можно же ошибку слать руками в момент завершения всех тестов но еще, так сказать, не выходя из контейнера. а сам контейнер завершать успешно, тестовый прогон ведь был выполнен, хоть и тест упал
- возможно, у вас назреет еще один вопрос - почему я задаюсь этим вопросом, не пусть себе завершается джоба с эррором, ведь в ней упавший тест. но! как тогда нам различать падение джобы произошло из-за ошибок ифнрастуктуры (не поднялся контейнер, не хватило памяти и т.д.) или упал тест? ну.. можно через еррор коды, но имхо, это геморно. или нет?
- скорее, в CI/CD системах (Jenkins, Gitlab, Github) упавшие джобы хендлить удобно и легко настроить алерты. но мои ранятся в GCP. и здесь падение джобы рассматривается как что-то аномальное и это вызывает некие проблемы с конфигурацией алертов. (например, мы будем получать алерт, пока не удалим упавшую джобу, даже если после нее уже была успешная)

поделитесь вашим опытом. буду рад комментариям 💪

Перепиши exit code

ребята, привет
нужно мнение экспертов )

есть у меня мониторинговые тесты - ранятся на проде с определенной периодичностью (например, 5 минут) и проверяют работоспособность продукта

вопрос касательно инфрастуктуры тестов – обязательно ли, чтобы джоба (с тестами) завершалась с ошибкой, когда падает тест?

приведу несколько аргументов от себя
- конечно, в стандартном CI/CD процессе упавшая джоба и стоп пайплайна - это маст хев. но в данном случае (помним, что тесты мониторинговые) стоп пайплайна нам не нужен, нам нужно только оповещение что именно упало
- назревает вывод, что раз мы должны знать, что есть падение, то и джобу нужно завершать с еррором. но можно же ошибку слать руками в момент завершения всех тестов но еще, так сказать, не выходя из контейнера. а сам контейнер завершать успешно, тестовый прогон ведь был выполнен, хоть и тест упал
- возможно, у вас назреет еще один вопрос - почему я задаюсь этим вопросом, не пусть себе завершается джоба с эррором, ведь в ней упавший тест. но! как тогда нам различать падение джобы произошло из-за ошибок ифнрастуктуры (не поднялся контейнер, не хватило памяти и т.д.) или упал тест? ну.. можно через еррор коды, но имхо, это геморно. или нет?
- скорее, в CI/CD системах (Jenkins, Gitlab, Github) упавшие джобы хендлить удобно и легко настроить алерты. но мои ранятся в GCP. и здесь падение джобы рассматривается как что-то аномальное и это вызывает некие проблемы с конфигурацией алертов. (например, мы будем получать алерт, пока не удалим упавшую джобу, даже если после нее уже была успешная)

поделитесь вашим опытом. буду рад комментариям 💪