仓库源文，站点原文

layout: post title: "折返点 2335 - 修复跑步页面的故障" date: "2023-09-05 10:49:31" categories: 折返点 auth: conge

tags: 跑步

content {:toc}

我有个一跑步页面，是基于 @yihong0618 的开源项目 running_page 通过 Github Actions 自动同步我的跑步数据，自动生成的。最近这个工作流忽然报错，说部署过程超时了。

本文记录一下这个错误以及修复过程。对了，我借着这次折腾的机会，给妻子的跑步也做了个数据页面，按此处查看。

工作流

我的跑步页面生成的整个工作流是这样的：

数据产生与共享：我通过 Garmin 手表记录自己的跑步。跑步完成后，数据会记录在 Garmin App 里，并且同步共享到 Starva。
数据更新：通过托管在 Github 的我的 Running page 项目的Run Data Sync workflow 从 Strava 同步数据到跑步页面项目。
页面构建与部署：如果有新数据， Run Data Sync 会触发启动 pages-build-demployment workflow，去创建并且部署新页面到 Running page 的gh-pages 分支。

以上步骤，1 会在我每次跑步之后完成。2 和 3 则的数据更新和是每天自动运行一次。

如果一切顺利，我的跑步页面就会更新到最新数据。如果第 2，3 步失败，我会收到邮件提醒。

问题

我从今年三月份第一次收到报错邮件，提示我 pages build and deployment 步骤失败。之后，同样的邮件，之后每个月大概会收到一次。

到了七月下旬，我收到报错邮件的频率开始提升。到了 8 月份，我更是收到了 8 次报错。

一开始我并没有在意，因为我知道，只要Run Data Sync 到数据更新没有问题，偶尔的页面构建失败没什么问题。只要页面更新步数成功一次，就会把页面带到最近的数据。

而且，除了利用 App 自动记录和更新数据，我自己有手动记录的习惯，数据都放在我跑步手动记录 github repo。

但越来越频繁的报错也实在是烦，于是我决定还是看一看。

诊断

我从 email 的链接进去，查看失败的工作流日志，马上就意识到了问题的所在：

我的生成的 gh-pages 居然有 5.4GB 之巨
巨大的文件造成整个 pages-build-demployment 需要 38 分钟多，且因为超时而失败。

为了查看这是不是个普遍问题，我按图索骥，找了其他几个用户 run page 项目，发现同样的工作流，别人都是两分钟内就完事儿，很多都还不到一分钟。而且，他们的文件大小只有几十或者一百多 MB，比我的要小很多。

我再次查看自己的日志，发现每次的部署更新，都会产生一些新文件，文件名类似于

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

这写文件大小不等，合起来也有 20 多 MB，这应该是 gh-pages 分支变大的原因。我大概我的 gh-pages 分支，发现里面文件数巨大，且都是 js.map 和 js 文件。这些文件就应该是罪魁了。

求助

这实在是很奇怪，但我也不知道怎么办，于是就在 running_page 的讨论页面提问。yihong0618 很快回复，认同是“gh-pages 这个分支太大”，并建议“删掉这个分支，都重新弄试试”。

修复

我按照 yihong0618 的建议操作，问题已经解决。

解决步骤：

删除 gh-pages 分支
到 Actions -> Workflows -> All Workflows 中，重新跑一次 Publish GitHub Pages 生成新的的 gh-pages 分支。
之后 pages build and deployment workflow 会被自动触发。

最终的结果，pages build and deployment 从之前的需要 38 分钟，变成了只需要 38 秒完成。分支大小也从 5.4 GB 变成了只有 14.5MB。变化巨大呀。