.dist это что-то типа балванки. Подразумевается что у тебя в твоем окружении будет свой parameters.yml

который будет чисто под энв

спасибо, но я не вижу там упоминания этого файла

а .dist используется как шаблон

спасибо, но я не вижу там упоминания этого файла

а там и не надо, суть в том что это просто yaml файлик с параметрами который импортится в конфиги

ты можешь его назвать хоть env_config.yml хоть yolo.yaml

главное что бы он импортился где-то в конфигах которые точно юзаются (config.yml какой)

никакой магии

это я примерно понял. Также я вижу, что запуск composer install/update как-то преобразует parameters.yml.dist в parameters.yml - где можно почитать, по какому алгоритму это делается?

это я примерно понял. Также я вижу, что запуск composer install/update как-то преобразует parameters.yml.dist в parameters.yml - где можно почитать, по какому алгоритму это делается?

открываешь composer.json и смотришь секцию scripts

и там есть некий parameters handler

вот его выкоси

https://packagist.org/packages/incenteev/composer-parameter-handler

и вообще, какого хрена ты делаешь composer install не на CI?)

эта либа занимается модификацией ямла

обычно

и вообще, какого хрена ты делаешь composer install не на CI?)

я готовлю Dockerfile для билда от git clone до docker push (а по пути всякие symfony new и composer install)

а потом это всё будет дёргаться через jenkins/ansible

я готовлю Dockerfile для билда от git clone до docker push (а по пути всякие symfony new и composer install)

выкинь parameters.yml и юзай env переменные

вот его выкоси

мне девелоперы выдали инструкцию по сборке, в которой сначала руками правится dist, потом запускается composer. К ним идти боюсь, наору ещё за то, что они сами в своих инструментах не шарят нихера

мне девелоперы выдали инструкцию по сборке, в которой сначала руками правится dist, потом запускается composer. К ним идти боюсь, наору ещё за то, что они сами в своих инструментах не шарят нихера

https://github.com/fesor/project-skeleton

с docker parameters.yml не то что не нужен - он будет сильно мешать

придется какие-то кастыли типа волумов делать

вшивать же креды в образ чет не ок

выкинь parameters.yml и юзай env переменные

идём к этому. Манагер решил, что проще меня заставить (сейчас) перелопатить 50 аппликух, чем заново всех разработчиков подстраивать под это

идём к этому. Манагер решил, что проще меня заставить (сейчас) перелопатить 50 аппликух, чем заново всех разработчиков подстраивать под это

скажи манагеру "а мы уже стали разработчиком и можем принимать технические решения??"

вшивать же креды в образ чет не ок

я в dist вставляю ${PARAM} в качестве величин. Потом заменяю при запуске, в образе нет ничего. Свой вариант .env

я в dist вставляю ${PARAM} в качестве величин. Потом заменяю при запуске, в образе нет ничего. Свой вариант .env

нафига?

yaml файлики не умеют интерполировать env переменные сами по себе

не умеют

ты можешь записать там значения вида %env(PARAM)%

хм

это вариант

спасибо

https://symfony.com/blog/new-in-symfony-3-2-runtime-environment-variables

а не, не вариант

это значит, мне надо будет искать это в config*.yml файлах и заменять

это задача разработчиков, мне нужен простой список параметров

но это то, к чему мы рано или поздно придём

это значит, мне надо будет искать это в config*.yml файлах и заменять

зачем? ты можешь это в parameters.yml юзать

временно хотя бы

но да, плетью разработчиков что бы чето делали

2018-ый год

проблема в том, что код даётся в виде библиотеки, потом создаётся приложение через symfony new. То есть у меня на руках файлов вообще никаких нет, всё надо динамически sed'ом и такой-то матерью делать. Ещё какие-то бандлы в AppKernel.php прописывать. Жуть, в-общем

если ещё принять во внимание, что с PHP моё общение закончилось в 2005-м ... :)

благодарю за помощь

проблема в том, что код даётся в виде библиотеки, потом создаётся приложение через symfony new. То есть у меня на руках файлов вообще никаких нет, всё надо динамически sed'ом и такой-то матерью делать. Ещё какие-то бандлы в AppKernel.php прописывать. Жуть, в-общем

а собрать свой шаблон symfony что бы не symfony new?

кстати, доп. вопрос со звёздочкой. В PHP/symfony есть общепринятый способ делать reproducible builds? C учётом того, что приложение может зависить от сторонних библиотек, которые ставятся через composer? Ну или best practices какие-нибудь?

CI

ну то есть по поводу composer - у него есть lock файл

потому composer install будет ставить только те версии которые уже ставились

я вообще composer install делаю в Dockerfile)

там только версии закрепить можно. Оно ещё всякий кэш и динамический код вроде может генерить

тот же secret в параметрах

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

а собрать свой шаблон symfony что бы не symfony new?

наверное можно, но для меня это тёмный лес

наверное можно, но для меня это тёмный лес

ну ты по сути это и делаешь)

там только версии закрепить можно. Оно ещё всякий кэш и динамический код вроде может генерить

это все вполне reproducable

symfony new? понятно тогда

если у тебя все на env переменных то можно кэш в dockerfile даже делать

если нет - то при старте контейнера чистить будешь

вся кодогенерация там в целом идемпотентна, то есть если код не менялся то и кэш будет такой же (ну хэши могут отличаться)

у меня multi-stage сборка, в одном контейнере до composer install доводится, результат переносится в чистый контейнер на базе php

вся кодогенерация там в целом идемпотентна, то есть если код не менялся то и кэш будет такой же (ну хэши могут отличаться)

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

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

не вижу смысла

если ты беспокоишься за кэш - делай это отдельным стэпом

тебе всеравно надо кэш чистить если что-то поменялось

ERROR: S client not available

за кэш докера*

речь про контрольную сумму файлов сборки.

расписывать зачем нужны reproducible builds думаю не надо :)

открываешь composer.json и смотришь секцию scripts

а если такой секции нет, то dist файл не используется?

а если такой секции нет, то dist файл не используется?

да, тогда ты ручками.

расписывать зачем нужны reproducible builds думаю не надо :)

ну тогда чисти кэш при старте контейнера что бы он не влиял на хэши образов и как следствие артифактов билдов

ну то есть блин

кэш это кэш, либо его тебе docker cache закэшит либо у тебя что-то в коде поменялось и кэш в любом случае будет отличаться

это не то из-за чего надо заморачиваться, так как при построении кэша не используется ничего стороннего. Завязано только на текущее время разве что но это влияет только на инвалидацию кэша (которая отключены в prod окружении)

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

(типа ей надо знать версию СУБД)

беда-беда-огорчение. Значит разраб мне в доке херню написал? Сначал пишет, что надо в parameters.dist.yaml что-то добавить, потом composer install, потом config*.yml, потом миграции, потом запуск.

беда-беда-огорчение. Значит разраб мне в доке херню написал? Сначал пишет, что надо в parameters.dist.yaml что-то добавить, потом composer install, потом config*.yml, потом миграции, потом запуск.

миграии у тебя должны быть вынесены из жизненного цикла контейнера по хорошему

ну то есть....

это отдельный вопрос, но я понял, о чём ты

у меня деплой прмиерно так: docker-compose pull ... docker-compose run --rm bin/console doctrine:migration:migrate -n docker-compose up -d

ну или чем ты там все стартуешь

беда-беда-огорчение. Значит разраб мне в доке херню написал? Сначал пишет, что надо в parameters.dist.yaml что-то добавить, потом composer install, потом config*.yml, потом миграции, потом запуск.

ну тут специфика того что у тебя разработчики творят херню какуюто поставляя код как библиотеку

могли бы делать проще

у нас это в swarm, у нас нет отдельного шага, в который можно запихнуть инит/миграции. Всё это перед стартом делается в entrypoint.sh

но это не вина разработчиков, конечно

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

они нам дали команды для миграции, просто мы их (пока) не отделили

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

проблемно, но не критично

в идеале, хотелось бы, чтоб всей этой херней они занимались, мне разбираться в symfony/composer не совсем интересно :)

мне бы архивчик и команды для сборки/теста/инициализации/запуска

понял я, composer.json берётся не из кода библиотеки, а создаётся во время symfony new, а там есть эти скрипты обработки paramerters.dist.yml. Разраб на это и рассчитывает и в доках эти шаги и указывает..

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

Как я понял чтобы думать о DDD надо сначала вообще понять про доменные модели и уметь их использовать. А потом уже DDD.

И сеттеры и геттеры это про доменные модели

Вернее их отсутствие

Laravel В a href написал session:flush Почему он при обновлении страницы сессию очищает А не при нажатии на ссылку?