А зачем мешать? Собрал проект, собрал контейнер с артифактом. Иначе ты нарушаешь single responsibility. Зачем в контейнере, который потом отправляется в прод гредл? Зачем ему знать как собрать проект?
Вижу ты не знаком со стадиями построения образа 🌚
> Зачем в контейнере, который потом отправляется в прод гредл? Гредл используется только для сборки. FROM gradle:jdk15 as builder Затем на прод отправляется чистый контейнер без гредла, но с артефактом взятым из предыдущей стадии (все в одном докерфайле) FROM openjdk:15 as backend COPY --from=builder /app/*.jar ./app
А мне кажется что вы сейчас пытаетесь уходить от темы путем необоснованного перехода на личности. Ответите на конкретные вопросы или оставьте за собой лычку неграмотного языкочесателя?
Этот подход имеет место, но это на совести его использующих
Даже сам вопрос показывает явное непонимание темы "а зачем гредл в контейнере на проде". Да нет там гредла. Гредл используется на стадии построения образа для получения артефакта.
Изначально об этом не было ни слова
мультистейдж же. в прод ничего не пойдет но в любом случае через условный дженкинс все равно будешь собирать гредлом в докере..
оба варианта будут работать) правда с раздельным вариантом проще в плане кеша
Ну работать то будет, можно и так и так. Но плюсы раздельного не только в кэше)
вообще да. просто помимо сборки еще б тесты прогнать и все такое
В ответ, кстати, тоже не стоит так делать. Вроде ж цивилизованный чат, ну :)
Ну я тоже подогрелся немного, неприлично, да)
Простите меня пожалуйста. Я необоснованно принял "бред" на свой счет, и, был реально неправ
Я рассматривал кейс когда мы хотим запускать много разных проектов, а из зависимостей на целевой машине иметь только docker.
Таки запускать или собирать?
Согласитесь, в таком случае, если собирать вне контейнера, могут возникать конфликты между зависимостями используемыми для сборки? Разные версии Python и JDK к примеру?
Так вы там собираете или запускаете? Или и то и другое?
1. В случае если речь о моей машине, то я хотел бы сразу запускать любые open-source проекты из исходного кода через docker-compose up, не озадачиваясь установкой зависимостей. 2. Если мы говорим о билд агентах, здесь опять таки, если используются разные версии зависимостей для разных собираемых сервисов, возникают конфликты, поэтому сборка в контейнерах также более чем оправдана.
1. Ну это персональные предпочтения 2. Так собирайте в докере, только в отдельном, о чем речь и шла Дальше я думаю продолжать не стоит, это оффтоп
2. Так ведь стадии с самого начала были разделены (в моем примере).
Обсуждают сегодня