来自Heroku的Django collectstatic每次都会推送到S3

Question

我正在使用django-storages来获取带有S3(和S3BotoStorage)的静态文件.当我从本地计算机执行collectstatic时,行为与预期一致,只有修改过的文件被推送到S3.此过程需要python-dateutils 1.5来检查修改时间.

但是,在Heroku上执行相同操作会导致每个文件都被推送,尽管设置是相同的.然后我查看了Heroku本身文件的修改时间,看起来,os.stat(static_filename).st_mtime与上次推送的时间相同.

这是预期的行为吗？即使git没有变化,heroku还能复制文件吗？

Answer 1

尝试设置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

我发现只需设置配置即可 - 不需要也启用user-env-compile- 可能是这已经从实验室进入生产阶段了？

NB部署由Heroku python buildpack管理,你可以在这里看到 - https://github.com/heroku/heroku-buildpack-python/

编辑1

我刚刚对此做了一堆测试,并且可以确认DISABLE_COLLECTSTATIC确实禁用了collectstatic,无论user-env-compile设置如何- 我认为现在已经在主干(但这是猜测).似乎不关心设置是什么 - 如果DISABLE_COLLECTSTATIC存在作为配置var使用它.

Answer 2

我强烈建议使用collectfast包对任何django静态部署到s3,无论是本地还是来自heroku服务器.它忽略了修改日期并利用md5哈希值,s3 api将非常快速地提供,并且(可选)缓存以使静态部署变焦.我的静态部署从大约10-15分钟到<2分钟,只部署了实际更改的文件.

Answer 3

我刚刚遇到了同样的问题,并联系了Heroku的支持,以了解发生了什么.我对他们的问题是

我在进行一些部署时遇到了一个时髦的问题.似乎在每次推送时,所有文件上修改的日期都会更新为新的部署/ git推送发生的时间.这是预期的行为吗？

当考虑Django的collectstatic命令仅在评估文件是否应该复制到静态资产的最终存储后端时检查文件的修改日期时,这意味着在每次新推送时,所有文件首先从远程存储中删除(在此案例S3)然后重新上传.就消耗的带宽和请求而言,这是一个非常缓慢且浪费的过程.

我今天从Heroku的支持人员之一"Caio"收到的答案是

嗨,这就是目前的工作方式,是的.我将您的反馈发送给我们的运行时团队,看看我们是否可以使用原始日期打包文件.