Комментарии 11
При изменении исходного кода пересобирать контейнер, серьезно?
Я ничего не имею против виртуализации сборки, так как это во-первых решает вопрос настройки окружения, во-вторых изолирует процесс сборки, т.е. есть уверенность, что если собралось на его машине, то соберется и на билд сервере, и у других разработчиков.
Лучше собрать контейнер со всем необходимым, при запуске контейнера монтировать каталог с исходным кодом (можно и каталог куда будут складываться результат сборки, чтобы они сохранялись между перезапусками контейнера). А разработчик вручную запускает сборку в контейнере (контейнер предоставляет консоль, X Server или в нем запущен ssh сервер). При изменнии исходного кода разработчик заново запускает сборку без пересборки контейнера.
Я ничего не имею против виртуализации сборки, так как это во-первых решает вопрос настройки окружения, во-вторых изолирует процесс сборки, т.е. есть уверенность, что если собралось на его машине, то соберется и на билд сервере, и у других разработчиков.
Лучше собрать контейнер со всем необходимым, при запуске контейнера монтировать каталог с исходным кодом (можно и каталог куда будут складываться результат сборки, чтобы они сохранялись между перезапусками контейнера). А разработчик вручную запускает сборку в контейнере (контейнер предоставляет консоль, X Server или в нем запущен ssh сервер). При изменнии исходного кода разработчик заново запускает сборку без пересборки контейнера.
+3
Ну, ничего плохого в сборке контейнера нету, но в этом примере стоило бы сделать дополнительные 2 контейнера с установленными зависимостями, чтобы не тратить зря кучу времени. Особенно, если деплой осуществляется при помощи этих контейнеров.
В результате для сборки будет только копироваться исходный код и скомпиленый бинарник, что заметно ускорит процесс.
А вот запуск сборки вручную — очень странная идея. Сборка должна быть по коммиту, как минимум, чтобы удостовериться, что код компилируется и тесты проходят. В противном случае добавляется человеческий фактор, который обычно выстреливает в самый неподходящий момент.
В результате для сборки будет только копироваться исходный код и скомпиленый бинарник, что заметно ускорит процесс.
А вот запуск сборки вручную — очень странная идея. Сборка должна быть по коммиту, как минимум, чтобы удостовериться, что код компилируется и тесты проходят. В противном случае добавляется человеческий фактор, который обычно выстреливает в самый неподходящий момент.
0
Я думаю под "вручную запускает сборку в контейнере" подразумевалось на хардкодить вызов cmake в Dockerfile, а использовать что-то типа: docker run build-container cmake /app && cmake --build ...
.
Кто и как будет выполнять эту команду — вопрос отдельный.
0
Возможны варианты. На текущем месте есть контейнер к которому я подсоединяюсь по VNC и запускаю сборку, запускаю приложение. Это удобно, так как развернуть все необходимое окружение, точнее осбрать все библиотеки довольно длителное занятие плюс они других версий от того, что используется для других проектов и могут возникнуть проблемы из-за этого.
Это было сделано в первую очередь, чтобы вновь пришедшим разработчикам не пришлом возиться со всем этим. Опять же, можно делать инкрементальную сборку, что может быть весьма актуально на больших проектах.
Это было сделано в первую очередь, чтобы вновь пришедшим разработчикам не пришлом возиться со всем этим. Опять же, можно делать инкрементальную сборку, что может быть весьма актуально на больших проектах.
0
точнее осбрать все библиотеки довольно длителное занятие плюс они других версий от того, что используется для других проектов и могут возникнуть проблемы из-за этого.
У нас решается это просто, есть отдельный репозиторий depends, в котором уже собраны либы для osx, windows, linux, asm.js. Цепляем все через cmake, поэтому для развертки требуется всего лишь компилятор и cmake.
+1
Сборка по коммиту при помощи docker реализовано в GitLab CI, поэтому тут говорить не о чем. Автор говорит именно об освобождении от настройки окружения:
Таким образом, освободив последующих разработчиков от необходимости тратить время на настройку локальной сборки.
+1
НЛО прилетело и опубликовало эту надпись здесь
Я с Вами согласен, но автор статьи или их смешивает в один, или говорит только про контейнер для локальной сборки на машине разработчика:
В результате мы создали полноценное C++ приложение, настроили окружение для его сборки и запуска под Linux и завернули его в Docker-контейнер. Таким образом, освободив последующих разработчиков от необходимости тратить время на настройку локальной сборки.
0
Почему в cmake используете, достаточно мощный, механизм find_package, но без его плюсов? Зачем эти глобальные include_directories и ${Boost_libraries}? Ведь гораздо лаконичнее писать Boost::program_info, GTest::main в target_link_libraries. Люди же стараются, пишут для вас find модули, а вы не пользуетесь.
+2
ENTRYPOINT нужно заменить на CMD иначе не будет работать корректное завершение работы контейнера. Ентрипоинт предназначен для предварительной подготовки контейнера к работе(к примеру создания пользователей базы данных при первом запруске)
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Docker для сборки и запуска проекта на C++