我的running page build+deployment的时间，居然需要半个多小时！

[conge]

我看了yihong0618的和其他几个朋友的build+deployment的action的记录，发现你们的都是半分钟一分钟就完事儿了.

再看了一下我的生成的gh-pages 居然有5.4GB之巨，而别人的只有几十一百多MB。

我的action report： https://github.com/conge/running_page/actions/runs/6061495948 ，
yihong的 https://github.com/yihong0618/running_page/actions/runs/5976375967
VintLin的：https://github.com/VintLin/Running/actions/runs/6044082866
iamjinlei0312的： https://github.com/iamjinlei0312/running_page/actions/runs/6055161102

这可能是什么的问题造成的呢？

谢谢！

[yihong0618]

@agassiyzh
@ben-29 @shaonianche

let us give a look

[conge]

谢谢

希望不是我做了什么傻事儿 :)

[conge]

我想很可能是因为我把 MIN_GRID_DISTANCE 设置的太低了，导致产生了大量的map文件的问题。

我刚刚改了一下，正在重新build, 看是不是就没问题了。大概过七八个小时回来给各位反馈。

[yihong0618]

@conge 应该不是。

目前查的原因是你的 gh-pages 这个分支太大了，不知道为什么。可能是我们问题。我查一下。。。
(你可以删掉这个分支，都重新弄试试

[conge]

的确是 gh-pages 这个分支太大导致的building和deployment的缓慢

但是 gh-pages变大的原因，应该是我每次更新都会生成新的类似于
e73e9428-0a91a86e97332d73eebc.js
e73e9428-0a91a86e97332d73eebc.js.map
425-1e1d4f0b9bbff1b9abc8.js.map
425-1e1d4f0b9bbff1b9abc8.js.
webpack-runtime-6af4f18872332333e62f.js
webpack-runtime-6af4f18872332333e62f.js.map
webpack.stats.json

等文件，

日积月累的，这些文件多起来的了，分支就胖打起来了。

至于是不是因为我把MIN_GRID_DISTANCE 设成3公里太低了，才使得大量产生map和相关文件，我就不知道了。

问题已经解决，解决步骤

1. 删除gh-pages 分支
2. 到 Actions -> Workflows -> All Workflows 中，重新跑一次 Publish GitHub Pages 生成新的的gh-pages 分支。

之后 pages build and deployment workflow会被自动触发， 38秒完成。

[yihong0618]

但是日积月累为啥会这么大啊。。。

[agassiyzh]

https://github.com/conge/running_page/actions/runs/5908439699/job/16027879745 看起来时间都花在actions/upload-pages-artifact上了。

[yihong0618]

clone 其实也挺离谱的，需要 clone 4 mins 我感觉可能我们 GitHub page 可以用 Actions 而不是用 branch?

[agassiyzh]

确实可以。有最近有空了改一改

[conge]

但是日积月累为啥会这么大啊。。。

我看了一下，我每次有新的跑步，就会生成几个.js,.js.map文件，合计约20多MB。
我每天跑，极少会跑3公里以下。
按照一年跑360次，每次产生20MB新文件估算，一年产生的文件大概会有20MB*360=7.2GB之巨呀。

我排查了一下build+deployment 那个workflow的log，随着时间的推移，artifacts的大小也是越来大，running time一开始确实也是几分钟，后来慢慢的越来越长，直到最后超过10分钟的限制，出现timeout错误。

我有两个个问题：是否那些新的.js,.js.map的产生受控于MIN_GRID_DISTANCE ？

解决方法也许是产生新的map文件的时候，删除或者覆盖旧有的，就行了？

[conge]

我觉得可以尝试每次有新数据更新，在构建页面和部署之前，不妨把 gh-pages 清空重来，就可以避免累积过多文件的问题了。

anyway, 把这次的事儿整理了一下，写下来了
https://conge.livingwithfcs.org/2023/09/05/ReturnPoint-running-page-fix/

感谢 @yihong0618 和 @agassiyzh 的帮助。

[yihong0618]

@conge 2.0 merge 了，已经改成 actions build