Как наломать велосипедов поверх костылей при тестировании своего дистрибутива

[@ultral]

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

[@selotec]

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

Не совсем понял по стилю повествования — это относится: к плюсам, к минусам, к непреложным фактам текущей реальности? Далее следуют выводы «Это позволило».
Хотелось бы прочитать, как обруливается данный момент, если он относится к минусам. Все таки нестабильное окружение и тестируемые сценарии вещь и злободневная, и интересная, а мало где можно почитать, как с таким справляются в сложных системах.

[@ultral]

Не совсем понял по стилю повествования — это относится: к плюсам, к минусам, к непреложным фактам текущей реальности

суровая действительность с которой приходится жить.

Хотелось бы прочитать, как обруливается данный момент, если он относится к минусам.

были не гласные договоренности:

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

в принципе почти стандартный giithub flow получился, с поправками:

• по каждому коммиту легковесные тесты гоняем
• артефактов храним минимум и только по релизным веткам

[@selotec]

Спасибо за пояснения.
Я правильно понимаю — это в основном аффектит ручные тесты? Или автоматические тоже?

[@ultral]

* Ручные — по релизным бранчам(собранным артифакатах)
* полный набор автоматических тестов по стабильным бранчам

[@ultral]

.