Итак, чтобы ответить на первоначальный вопрос о том, где генерируются public / assets - ответ будет «во время создания» или «во время сборки, если у вас их нет, и если вы загружаете пустой каталог». Надеемся, что после слияния PR, упомянутого ниже, ответ на этот вопрос будет «во время создания или во время сборки, если они еще не существуют в вашем репо (то есть, потому что они gitignored)».
Две точки (почему локальная сборка не генерирует их + почему Docker build не генерирует их) имеют совершенно не связанные и разные ответы, поэтому я буду рассматривать их каждый в отдельных пунктах.
Мы обнаружили, что на самом деле, в зависимости от состояния вашего хранилища, если вы теряете / удаляете файлы веб-пакета, среда буйвола не восстанавливает их для вас, и в любом случае это не ошибка, потому что Это допустимый вариант использования для запуска буйвола без генерации каких-либо активов (хотя это не тот вариант использования, который мне кажется очень полезным, возможно, стоит предложить изменение, чтобы сделать буйвола более самоуверенным в этом отношении).
Что касается самой сборки Docker, кажется, что если вы добавите оператор mkdir, чтобы убедиться, что public / assets существуют до запуска сборки Buffalo (т.е. в вашем Dockerfile), то вы можете компенсировать тот факт, что вы игнорируете этот каталог, и он будет правильно заполнен в статической сборке.
Поскольку последний вариант использования является более важным, я создал запрос на извлечение для решения этой проблемы (то есть, чтобы вам не нужно было вручную добавлять шаг mkdir public / assets) под руководством сообщества буйволов, которое можно найти здесь:
https://github.com/gobuffalo/buffalo/pull/1447.
Короче говоря: до слияния PR, если вам нужны ваши ресурсы для создания ваших развертываемых объектов (что вы, вероятно, делаете), либо удалите строку public / assets из gitignore и передайте их для контроля версий, чтобы ваш код мог быть непосредственно собран без внешних зависимостей, ИЛИ просто убедитесь, что вы строите свой код в том же месте, где вы запускаете Buffalo Dev. Если есть третий ответ. Первое, с моей точки зрения, является более дружественным к облакам решением, но я новичок в буйволах, так что я могу неправильно понять идиомы.
Отказ от ответственности: я отвечаю на этот вопрос, потому что думаю, что он может быть полезен для людей, но я не эксперт по буйволам. Существуют гораздо более глубокие технические точки зрения на то, как активы работают с документами на буйволов. / веб-сайт (https://gobuffalo.io/en/docs/assets)