Cherry Markdown项目PR合并后自动清理预览资源的实现方案

在协同开发场景下，代码审查是保证代码质量的重要环节。Cherry Markdown作为一款优秀的开源Markdown编辑器，其PR（Pull Request）在线预览功能为代码审查提供了便利。然而，随着项目迭代，这些预览资源会逐渐积累，占用存储空间并可能引发安全问题。本文将深入探讨如何实现PR合并后自动清理预览资源的解决方案。

技术背景

现代代码托管平台通常提供PR预览环境，允许开发者查看代码变更的实际效果。对于Cherry Markdown这样的富文本编辑器项目，预览功能尤为重要，因为它能直观展示Markdown渲染效果的变化。但这些预览资源具有明显的临时性特征：

1. 生命周期短暂：仅在PR审查期间有效
2. 资源占用显著：包含静态文件、构建产物等
3. 安全敏感性：可能包含未合并的试验性代码

实现方案设计

核心机制

通过GitHub Actions的工作流触发器，监听PR的合并事件（pull_request.closed），当检测到PR被合并时自动执行清理脚本。该方案包含三个关键组件：

1. 事件监听器：配置工作流仅在PR合并时触发
2. 权限控制系统：确保只有可信操作能执行清理
3. 资源清理器：精确识别并删除预览相关资源

技术实现细节

name: Clean Preview Resources
on:
  pull_request:
    types: [closed]
jobs:
  clean-up:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Clean preview resources
        run: |
          # 识别预览资源路径
          PREVIEW_DIR="./previews/pr-${{ github.event.pull_request.number }}"
          
          # 安全验证与清理
          if [ -d "$PREVIEW_DIR" ]; then
            echo "Cleaning preview resources..."
            rm -rf "$PREVIEW_DIR"
          fi

安全考量

1. 双重验证机制：同时检查PR关闭状态和合并状态
2. 路径隔离：每个PR的资源存储在独立目录
3. 权限最小化：工作流仅需项目读取和写入权限

方案优势

相比手动清理，自动化方案具有以下显著优势：

1. 资源利用率提升：及时释放存储空间
2. 安全性增强：避免敏感代码残留
3. 维护成本降低：无需人工干预
4. 系统稳定性：不影响正在进行的其他PR预览

实施建议

对于类似项目实施此类方案时，建议：

1. 渐进式部署：先在测试仓库验证效果
2. 监控机制：添加清理日志记录
3. 异常处理：考虑网络故障等边缘情况
4. 通知系统：可选地添加清理完成通知

总结

Cherry Markdown项目通过自动化清理机制，有效解决了PR预览资源堆积问题。该方案体现了DevOps实践中"自动化一切可自动化"的原则，不仅适用于Markdown编辑器项目，也可为其他需要PR预览功能的开源项目提供参考。实现过程中展现的事件驱动设计、安全边界划分等技术决策，值得同类项目借鉴。