Ооо, ламповый hangouts

запульнул в закладки

давай ты конкретнее вопросы задашь

могу в личку?

неа :)

Всем интересно!) По теме же

всем интересно жи.

с e2e-тестами для серверов сильно помогает docker-compose, но это не новость уже наверно

> неа :)
ок.

У меня есть такая боль:

Мы делаем:
1. мы делаем sdk (lin/win/mac) - тут все более менее понятно с ci и тестированием. наклепал gitlab-раннеров с запасом или включил скейлинг и погнали.

2. мы делаем "платформу" где надо делать e2e на линуксе
Пока больно от композов, потому что хелсчеки, ожидание старта зависимостей и тд

КАк вы реализуете п.2
желательно подробно, типа "мы собираем образ докера такой, именуем его так, потому что так, пушим его туда и туда потомучто так"

если кому-то интересно, про TeamCity, я когда-то рассказывал как мы оборачиваем Docker в билдах, там получился целый десяток красивых фич
https://www.youtube.com/watch?v=0w6Uv8MByVA

> хелсчеки, ожидание старта зависимостей и тд
вот кстати, одна из фичей :)

build once, deploy many
сборка артефактов - это одна джоба, запуск в тестах - другая, деплойменты - следующие.
у нас всё построено на зависимостях между билд-конфигурациями. по пайплайну едут либо бинарные артефакты, либо имена версий (docker-тегов в данном случае)

А что за зависимости между билд-конфигурациями?

каждый билд на выходе дает
- green/red статус
- логи
- бинарные артефакты, которые хранятся внутри TeamCity-сервера или в S3
- статистику и тест-репорты
- мапу метаданных про билд

Ага, понятно.
А билды у вас зависят друг от дружки. И вы строите цепочки из них, так?

если билд компиляции сгенерил jar-файлы, билд c тестами просто их получит
если билд сгенерил docker-имидж и запушил его во внешний registry, билд с тестами файлов не получит, но получит значение тэга из метаданных

если очень грубо, то аналогии примерно такие
project = pipeline
build configuration = stage

а, понял.
Я под "билдом" подразумевал целый пайплайн

Это ты сразу с gitlab аналогию провел?

с Jenkinsfile