Да, с параметрами плюс минус одинаково

Это функциональный мониторинг, т.е. это обычные тестовые сценарии, как и на UI, просто на уровне ниже (API, HTTP JSON). Тестовые сценарии(логика) - одна, но она использует много генераторов и получаем что-то близкое к property-based testing

Тестовый сценарий имеет либо True либо False в конце, если True - просто инкрементируются метрики для прометеуса, если False - допонительно пишется в БД(mongodb)

Вот

Короче, это изи, ща

У меня разница в моделях лишь в том, что они по сути (если смотреть из внешнего мира) используют разные host:port + middleware (т.е. одна направлена на одно окружение, другая - на другое)

1) Создаешь по джобе на каждую "модель" (набор данных с которым запускаешь пайтест)
2) Ставишь таймер на каждую джобу ("бесконечный" запуск каждую минуту, например)
2) Из аллюр-отчета берешь allure-report/export/influxDbData.txt
3) Загружаешь это в свой инфлюкс (либо любым другим способом обрабатываешь результат сборки, хоть из степа сборки, хоть из хука pytest_configure)
4) Настраиваешь алерт в графане

Соот-но джоба может быть одна, но запускаться с разными параметрами, или на месте инфлюкса + графана будет ваш собственный велосипед, это неважно уже.

Просто у тебя есть тесты, есть сборка. Если сборка не ок -- нужно куда-то сообщить об этом.

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

Сборка в смысле того сервиса, который тестирую?

Сборка в смысле прогон тестов.

Если это мониторинговый прогон, то каждый раз пересобирать продовую версию сервиса -- максимально неправильно. Потому что вместо мониторинга, будет тестирование билда.

Инфраструктурное взаимодействие понятно, спасибо

Главный вопрос все равно открыт :(

2) Ставишь таймер на каждую джобу ("бесконечный" запуск каждую минуту, например)

Вот тут - мы что, билд агент занимаем навсегда?

Да

Ну, а как ты хочешь? Чтобы оно работало, но не требовало ресурсов?

Не очень звучит, так как сейчас это красиво деплоится в нужную машину и просто сидит как сервис

Видишь, как хорошо. В чем вопрос тогда?

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

Сервис для запуска пайтеста с определенными параметрами))

Изначально, проблемы три:
1) Отсутствие pytest и голый fastapi - костыли в виде сборки тестов, дубликат кода (нет фикстур);
2) Медленные e2e тесты (голый asyncio давал мне максимум 830 RPS), добавим все говно, что написал и всякие ожидания, получаем 2-5 RPS
3) жор памяти(

Как уже верно отметили, переписать это на условный rust/golang да хоть сишку - будет плюс минус бесполезным занятием, так как если алгоритм плохой, то ничего не поможет (если я там улетел уже в какой-нибудь n^2 или даже n^3