Есть общепринятая практика в репозитории хранить composer.lock и выполнять composer install при установке проекта.
Я так понимаю, основная цель - уменьшить потребление диска репозиториями.
У меня это регулярно создает проблемы.
Последние года два я запускаю сайты в контейнерах, и на самом сервере я не ставлю ни php, ни mysql.
1. Чтобы выполнить composer install мне надо сначала зайти в контейнер `docker exec -ti a9 /bin/sh`, потом в нем установить composer, и потом выполнить composer install.
Сomposer - не часть OS, не часть php, как был pear, и не часть приложения.
Следствие: у контейнера с php появляется внешний артефакт - composer, который нужен один раз.
Можно добавить composer в образ при сборке, но это как корове седло - у него отдельные от php релизы.
Можно ставить composer в контейнер при первом запуске службы, это просто небольшая лишняя работа.
2. Чтобы поставить vendors, нужны права записи php в контейнере в vendors/, и открырый исходящий трафик. А зачем они процессам, которые обрабатывают только входящий трафик?
3. Завсисимость от сторонних ресурсов
4. Из всего этого вытекает отдельный build-процесс, который должен собрать пакет, доставить его на POD или вместе с vendors, или выполнить composer install -o.
А какие средства доставки? Баду когда-то раскатывали образ FS, но мне такие навороты не нужны. Gitlab использует свой же репозиторий и докер-образы - вышли снова на Дерибасовскую.
Что я делаю не так, почему мне все время хочется один раз запушить vendors в git, и забыть о нем?
Я так понимаю, основная цель - уменьшить потребление диска репозиториями.
У меня это регулярно создает проблемы.
Последние года два я запускаю сайты в контейнерах, и на самом сервере я не ставлю ни php, ни mysql.
1. Чтобы выполнить composer install мне надо сначала зайти в контейнер `docker exec -ti a9 /bin/sh`, потом в нем установить composer, и потом выполнить composer install.
Сomposer - не часть OS, не часть php, как был pear, и не часть приложения.
Следствие: у контейнера с php появляется внешний артефакт - composer, который нужен один раз.
Можно добавить composer в образ при сборке, но это как корове седло - у него отдельные от php релизы.
Можно ставить composer в контейнер при первом запуске службы, это просто небольшая лишняя работа.
2. Чтобы поставить vendors, нужны права записи php в контейнере в vendors/, и открырый исходящий трафик. А зачем они процессам, которые обрабатывают только входящий трафик?
3. Завсисимость от сторонних ресурсов
4. Из всего этого вытекает отдельный build-процесс, который должен собрать пакет, доставить его на POD или вместе с vendors, или выполнить composer install -o.
А какие средства доставки? Баду когда-то раскатывали образ FS, но мне такие навороты не нужны. Gitlab использует свой же репозиторий и докер-образы - вышли снова на Дерибасовскую.
Что я делаю не так, почему мне все время хочется один раз запушить vendors в git, и забыть о нем?
Последнее редактирование:
