но pull тоже не лучшая вещь, при push -f он ломается

это всегда COPY и всегда контейнер на проект

Разделять можно разными волюмами которые указывать при запуске билд контейнера

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

Но зачем оно тогда? почему ты не сделать тогда клон?

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

ну хорошо, идеи здравые, спасибо, буду обдумывать детатали. Но вот тогда другая проблема. Допустим, есть у нас этот билд-контейнер, который каким-то образом получает сорцы и потом выплевывает в хост-систему какой-то собранный артифакт. Дальше нужно создать имадж новой версии с этим этим артифактом и сделать пуш в докер-регистри. Как при создании имаджа с приложением узнать, в какую папку был сохранен собранный артифакт? Т.е. мне надо при создании билд-контейнера заложиться на какую-то одну папку в хостовой системе, и потом при сборке имаджа с приложением каждый раз вспоминать, где эта папка находится на текущей системе. Я понимаю, что универсальный ответ "возьми gitlab и не мучайся". Но мне вот приспичило в самолете собрать на ломальной машинке весь проект, запустить его в минимальном окружении и пригнать тесты. Все кэши есть, сорс код вот лежит в папке, докер с имаджами есть.

Что-то я совсем не понимаю что вы пишете. Зачем плеваться артефактами в хост систему? Почему нельзя в билд контейнере все что нужно сделать, в том числе пушнуть в регистри?

ну добавьте, в чем проблема? -v /var/lib/docker.sock:/var/lib/docker.sock

Аргументируете?

Что бы это значило....

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

Что бы это значило....

можете, в принципе, через http-api прицепиться

ну добавьте, в чем проблема? -v /var/lib/docker.sock:/var/lib/docker.sock

Теперь внутрь еще один докер,а в нем докер в докере

тогда еще такой вопрос, наверное тоже зависит от ситуации, но все же. Насколько противоречит философии докера билд приложения внутри контейнера(клон кода внутрь контейнера, и какой нить composer собирает все зависимости). Цель - иметь саморазворачивающуюся среду для разработки по docker-compose up. И есть ли возможность вынести код наружу что бы разработчик мог править непосредственно код из докера?

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