Использование Docker для сборки и запуска проекта на C++

[Hokum]

При изменении исходного кода пересобирать контейнер, серьезно?

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

Лучше собрать контейнер со всем необходимым, при запуске контейнера монтировать каталог с исходным кодом (можно и каталог куда будут складываться результат сборки, чтобы они сохранялись между перезапусками контейнера). А разработчик вручную запускает сборку в контейнере (контейнер предоставляет консоль, X Server или в нем запущен ssh сервер). При изменнии исходного кода разработчик заново запускает сборку без пересборки контейнера.

[Shtsh]

Ну, ничего плохого в сборке контейнера нету, но в этом примере стоило бы сделать дополнительные 2 контейнера с установленными зависимостями, чтобы не тратить зря кучу времени. Особенно, если деплой осуществляется при помощи этих контейнеров.

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

А вот запуск сборки вручную — очень странная идея. Сборка должна быть по коммиту, как минимум, чтобы удостовериться, что код компилируется и тесты проходят. В противном случае добавляется человеческий фактор, который обычно выстреливает в самый неподходящий момент.

[SilentBob]

Я думаю под "вручную запускает сборку в контейнере" подразумевалось на хардкодить вызов cmake в Dockerfile, а использовать что-то типа: docker run build-container cmake /app && cmake --build ....

Кто и как будет выполнять эту команду — вопрос отдельный.

[Hokum]

Возможны варианты. На текущем месте есть контейнер к которому я подсоединяюсь по VNC и запускаю сборку, запускаю приложение. Это удобно, так как развернуть все необходимое окружение, точнее осбрать все библиотеки довольно длителное занятие плюс они других версий от того, что используется для других проектов и могут возникнуть проблемы из-за этого.

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

[RPG18]

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

У нас решается это просто, есть отдельный репозиторий depends, в котором уже собраны либы для osx, windows, linux, asm.js. Цепляем все через cmake, поэтому для развертки требуется всего лишь компилятор и cmake.

[Hokum]

Репозиторий depends — это очень хорошее решение. Я пришел в компанию не давно, а тут так сложилось. В данный момент пробую все перетащить на менеджер зависимостей conan.

[RPG18]

Сборка по коммиту при помощи docker реализовано в GitLab CI, поэтому тут говорить не о чем. Автор говорит именно об освобождении от настройки окружения:

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

[Hokum]

Я с Вами согласен, но автор статьи или их смешивает в один, или говорит только про контейнер для локальной сборки на машине разработчика:

В результате мы создали полноценное C++ приложение, настроили окружение для его сборки и запуска под Linux и завернули его в Docker-контейнер. Таким образом, освободив последующих разработчиков от необходимости тратить время на настройку локальной сборки.

[xroft]

Почему в cmake используете, достаточно мощный, механизм find_package, но без его плюсов? Зачем эти глобальные include_directories и ${Boost_libraries}? Ведь гораздо лаконичнее писать Boost::program_info, GTest::main в target_link_libraries. Люди же стараются, пишут для вас find модули, а вы не пользуетесь.

[wir_wolf]

ENTRYPOINT нужно заменить на CMD иначе не будет работать корректное завершение работы контейнера. Ентрипоинт предназначен для предварительной подготовки контейнера к работе(к примеру создания пользователей базы данных при первом запруске)

[Pubert]

Entrypoint = точка входа, а то, что передаётся в CMD, "добавляется" к entrypoint. Так что корректное завершение работы контейнера будет (exit with 0 status). Вы, возможно, путаете с RUN - вот это действительно предварительная настройка. Точнее, каждая команда RUN создаёт новый слой собираемого образа