Django collectstatic от Heroku каждый раз отправляет на S3

Попробуйте установить DISABLE_COLLECTSTATIC=1 в качестве параметра среды для вашего приложения — это должно отключить его запуск при каждом нажатии.

Подробнее см. в этой статье — https://devcenter.heroku.com/articles/django-assets :

> Sometimes, you may not want Heroku to run collectstatic on your behalf.
> You can disable collectstatic by enabling user-env-compile as well:

$ heroku labs:enable user-env-compile
$ heroku config:set DISABLE_COLLECTSTATIC=1

Обратите внимание, что развертывание управляется сборочным пакетом Heroku python, который вы можете увидеть здесь — https://github.com/heroku/heroku-buildpack-python/

ИЗМЕНИТЬ 1

Я только что провел несколько тестов и могу подтвердить, что DISABLE_COLLECTSTATIC действительно отключает collectstatic, независимо от настройки user-env-compile — я думаю, что он сейчас находится в основном транке (но это предположение). Кажется, все равно, что это за настройка - если DISABLE_COLLECTSTATIC существует как переменная конфигурации, она используется.

Я настоятельно рекомендую использовать пакет collectfast для любого статического развертывания django на s3, локально или с вашего сервера heroku. Он игнорирует измененные даты и использует хэши md5, которые API s3 предоставит очень быстро, и (необязательно) кэширование, чтобы увеличить ваши статические развертывания. Мои статические развертывания заняли от ~ 10-15 минут до ‹ 2 минут, и я развертывал только те файлы, которые действительно изменились.

У меня только что была такая же проблема, и я связался со службой поддержки Heroku, чтобы узнать, что происходит. Мой вопрос к ним был

Я столкнулся с забавной проблемой при некоторых развертываниях. Похоже, что при каждом нажатии дата, измененная во всех файлах, обновляется до времени, когда происходит новое развертывание/удаление git. Это намеренное поведение?

Учитывая, что команда Django collectstatic проверяет дату изменения файлов только при оценке того, следует ли копировать файл в конечное хранилище для статических ресурсов, это означает, что при каждом новом нажатии все файлы сначала удаляются из удаленного хранилища (в этот случай S3), а затем повторно загружен. Это очень медленный и расточительный процесс с точки зрения потребляемой полосы пропускания и выполненных запросов.

Ответ, который я получил сегодня от «Кайо», одного из сотрудников службы поддержки Heroku, был

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

Как подтвердил Ален, Heroku меняет дату изменения файлов при развертывании. Однако в Amazon S3 также есть атрибут etag, представляющий собой хэш md5 содержимого файла. Это можно использовать для проверки того, изменились ли файлы вместо даты изменения, как это реализовано в этом фрагменте кода Django.

Я взял этот код, упаковал его, исправил некоторые найденные ошибки и поместил на Github как django-s3- собирать статический. Он включает новую команду управления fasts3collectstatic, которая загружает только новые файлы. Проверьте страницу Github для получения инструкций по установке.

Почему бы не запустить collectstatic с локальной машины?

python manage.py collectstatic --noinput --settings=settings.[prod]

Я согласен, что это раздражает - есть пара вещей, которые вы можете сделать. Я переопределяю команду collectstatic и подключаю ее в своих производственных настройках. Ниже приведена команда, которую я использую:

```

from django.core.management.base import BaseCommand
class Command(BaseCommand):
    args = '< none >'
    help = "disables collectstatic cmd in contrib"
    def handle(self, *args, **kwargs):
        print 'collectstatic disabled'

```

Я храню это в mysite/disablecollectstatic/management/commands Затем в производственных настройках:

INSTALLED_APPS += ('mysite.disablecollectstatic',)

В качестве альтернативы вы можете использовать тот факт, что Heroku сначала выполняет пробный запуск, прежде чем фактически вызывать команду. В случае сбоя он не запустится, а это значит, что вы можете выдумать ошибку (например, удалив статический корень в настройках), но такой подход меня нервирует:

https://devcenter.heroku.com/articles/django-assets#detection