我之前也碰到过类似的情况，Exit Code 15这个错误其实很容易被误解——它不是你的代码或者Jekyll配置有问题，大概率是CI进程被外部信号终止了（对应SIGTERM），比如超时、资源耗尽这类环境层面的问题。结合你说的「生产构建成功、代码和工作流没改」的情况，给你几个具体的排查和解决方向：

1. 先搞懂Exit Code 15到底意味着什么 #

这个退出码对应的是系统发送的终止信号，不是Jekyll编译或依赖安装的错误。换句话说，你的构建过程本身没出错，是CI运行环境因为某种原因把它叫停了。常见的触发原因有两个：构建超时或者内存不足被OOM Killer干掉。

2. 先查测试工作流的超时和资源情况 #

• 去GitHub Actions的日志里翻一翻，看看最后终止前有没有类似「Timeout reached」的提示。GitHub免费版的单任务默认超时是35分钟，如果你的dev分支测试构建比生产分支多了一些步骤（比如额外的链接检查、测试用例），很可能触发超时。
• 可以在工作流里加个简单的内存监控步骤，看看构建过程中内存是不是不够用：

  - name: 检查内存使用
    run: free -h
  

  把这个步骤放在Jekyll构建之前，对比生产分支的日志，就能看出资源差异。

3. 对比Dev和生产分支的构建内容差异 #

虽然你说代码没改，但可能存在这些隐藏差异：

• Dev分支里有没有新增的大文件、未清理的草稿（_drafts目录）或者临时生成的内容？这些都会让Jekyll在构建时处理更多数据，加重负载。
• 有没有分支专属的配置文件？比如_config.dev.yml，可能里面开启了更多插件或者生成选项，比如future: true显示未来的文章，导致构建量变大。

4. 强制重置CI的Gem缓存 #

有时候CI的缓存会出问题，虽然日志说「已构建所有必要gems」，但缓存的依赖可能损坏或者不完整。你可以试试：

• 在测试工作流里加一步清理缓存：

  - name: 清理Gem缓存
    run: bundle clean --force
  

• 或者直接去仓库的「Settings → Actions → Cache」里找到对应测试工作流的缓存，手动删除，让CI重新安装所有依赖。

5. 本地模拟测试构建环境 #

在本地复现GitHub Pages的测试环境，看看能不能重现问题：

• 用github-pages gem本地构建：

  bundle exec jekyll build --config _config.yml
  

  如果是测试环境有专属配置，就加上对应的配置文件。
• 构建时观察本地的内存和CPU占用，如果本地也出现卡顿或者进程终止，那说明dev分支的构建负载确实比生产分支高，得优化内容。

6. 调整测试工作流的资源配置 #

如果确认是资源问题，可以试试这些调整：

• 延长超时时间：在工作流的job里加上timeout-minutes: 60（GitHub最大允许60分钟）。
• 拆分任务：把测试和构建分成两个独立的job，减少单任务的负载。
• 如果有条件，用自托管runner，配置更大的内存和CPU，避免GitHub默认runner的资源限制。

内容的提问来源于stack exchange，提问作者Pedro Palazzo