前言：在 Jenkins 持续集成过程中，构建记录、工作空间、产物包会不断积累，既占用磁盘空间，也会让构建历史变得臃肿。Jenkins 自带的“丢弃旧的构建”功能和 Discard Old Build 插件，是两种常见的构建清理方案。本文将详细对比两者，并通过实操演示帮助你选择最适合的策略。
一、核心对比：Jenkins 自带功能 vs Discard Old Build 插件
| 特性 | Jenkins 自带功能（丢弃旧的构建） | Discard Old Build 插件 |
|---|---|---|
| 安装依赖 | 无需安装，Jenkins 默认自带 | 需要手动安装（额外维护成本） |
| 配置难度 | 简单，Job 配置中直接勾选配置 | 稍复杂，需学习插件专属策略配置 |
| 清理策略 | 仅支持 按「构建数量」或「天数」 清理 | 支持更多维度： - 按构建状态（成功/失败/不稳定） - 按分支/标签过滤 - 按磁盘空间阈值触发 - 多条件组合逻辑 |
| 实时清理 | 否，需等待新构建触发后执行清理 | 否，仍需构建触发，但可结合条件更灵活触发 |
| 适用场景 | 单一规则（如 保留最近 3 次构建） | 复杂场景（多分支管理、磁盘保护、差异化保留特定构建） |
| 风险 | 无额外风险，官方原生功能 | 插件版本更新不及时可能引发 Jenkins 兼容性问题 |
| 维护成本 | 低（无需关注插件版本） | 中等（需关注插件更新与兼容性） |
二、决策流程图：如何选择清理方案？
三、实操：Jenkins 自带“丢弃旧的构建”功能（简单场景 + 发布包参数详解）
场景范例：某项目需实现两个核心目标：
- 构建记录层面：仅保留最近 3 次构建记录，不通过“天数”额外限制；
- 发布包层面：仅保留“最近 1 天内 + 最近 1 次构建”生成的发布包（如
jar/war等部署产物），且不删除最新一次构建的发布包。
步骤 1：进入任务配置页
- 登录 Jenkins 平台，找到目标任务（如截图中的任务），点击进入任务详情页。
- 点击左侧菜单栏的 “配置” 选项，进入任务配置界面。
步骤 2：配置“构建记录”的核心保留规则
在配置页面中，找到并勾选 “丢弃旧的构建”（启用自动清理功能），然后设置基础规则：
- 保持构建的天数：清空输入框（表示“不按‘天数’限制构建记录的保留周期”）。
- 保持构建的最大个数：输入
3（表示“仅保留最近 3 次构建记录”）。
步骤 3：详解“发布包专属参数”（对应截图中3个参数）
在“丢弃旧的构建”区域，点击 “高级” 展开发布包配置，以下是对3个参数的详细解释：
1. 发布包保留天数
- 作用：仅针对“发布包文件”，按“时间周期”控制保留时长。
- 配置逻辑：若填写非空值（如当前配置为
1），则生成超过 1 天的发布包会被自动删除，但该次构建的日志、操作历史、测试报告等“非产物类记录”会被保留。 - 场景匹配：填
1后，“发布包生成超过 1 天”就会触发清理，而构建记录本身（如构建编号、日志）仍由上方“保持构建的最大个数（3）”规则管理。
2. 发布包最大保留#个构建
- 作用：仅针对“发布包文件”，按“构建次数”控制保留数量。
- 配置逻辑：若填写非空值（如当前配置为
1），则只保留最近 1 次构建生成的发布包，更早构建的发布包会被自动清理（但不影响构建记录的保留）。 - 场景匹配：填
1后，“不管发布包生成多久，仅留最近 1 次构建的发布包”；与“发布包保留天数（1）”形成“或逻辑”——发布包“超过 1 天”或“不是最近 1 次构建的”，都会被清理。
3. Remove last build（是否删除最后一次构建）
- 作用：控制“最新一次构建”的发布包（及关联资源）是否会被清理规则影响。
- 配置逻辑：
- 选 “是”：最新一次构建的发布包、日志等所有资源，都可能被清理规则删除（不推荐，会丢失最新版本的追溯性）。
- 选 “否”（当前选中状态）：最新一次构建的发布包、日志等资源不会被清理，仅清理更早的构建相关资源。
- 场景匹配：选“否”，确保“最新一次构建的发布包”始终保留，方便紧急回滚或版本验证。
步骤 4：保存配置
点击页面底部的 “Save” 按钮，使“构建记录保留 + 发布包保留”的所有配置生效。
效果验证逻辑
- 构建记录：新构建触发后，若历史构建数超过 3 次，最旧的构建记录会被自动清理，最终仅保留最近 3 次。
- 发布包：
- 超过 1 天的发布包，会被“发布包保留天数（1）”清理；
- 非最近 1 次构建的发布包，会被“发布包最大保留#个构建（1）”清理；
- 最新一次构建的发布包，因“Remove last build = 否”，始终保留。
步骤 5：效果验证
配置保存后，后续每次新构建触发时，Jenkins 会自动执行分层清理逻辑：
- 构建记录维度：若历史构建数量超过 3 次，最旧的构建记录会被自动删除，最终仅保留最近 3 次构建的完整元数据（包括构建日志、操作历史、测试报告等）。
- 发布包维度：
- 生成时间超过 1 天的发布包，会被“发布包保留天数（1）”规则清理；
- 不是“最近 1 次构建”生成的发布包，会被“发布包最大保留#个构建（1）”规则清理；
- 最新一次构建生成的发布包，因“Remove last build = 否”，会始终保留（方便紧急回滚、版本验证等场景）。
这套配置既通过 构建个数限制 控制了历史记录的整体规模，又通过 发布包专属规则 精细化管理了部署产物的存储占用，最终实现 轻量化存储 + 关键版本可追溯 的平衡。
四、实操：Discard Old Build 插件（复杂场景）
场景范例：某多分支项目需“保留 main 分支最近 5 次成功构建，其他分支仅保留最近 2 次构建；且当磁盘占用超 80% 时，强制清理所有分支的旧构建”。
步骤 1：安装 Discard Old Build 插件
- 进入 Jenkins 首页，点击左侧 “Manage Jenkins” → “插件管理”。
- 切换到 “可选插件” 标签页，在搜索框输入
Discard Old Build。 - 找到插件后，勾选左侧复选框，点击 “直接安装”（或“下载待重启后安装”，根据 Jenkins 状态选择）。
- 等待安装完成（页面会显示安装进度，完成后可查看“已安装插件”确认）。
步骤 2：进入任务配置页
同“自带功能”步骤 1，进入目标任务（如 MultiBranch-Project）的配置界面。
步骤 3：配置 Discard Old Build 策略
-
下拉页面，找到 “构建后操作” 区域，点击 “添加构建后操作” → 选择 “Discard old builds (advanced)”（插件提供的高级清理选项）。
-
配置核心策略（以场景需求为例）：
- General Settings（通用设置）：
Days to keep builds：留空（不按天数全局限制）。Max # of builds to keep：留空（不按全局个数限制，改为分支级控制）。
- Branch-Specific Rules（分支特定规则）：
点击 “Add Branch Rule”，配置main分支规则：Branch Name：输入main（匹配主分支）。Days to keep builds for this branch：留空。Max # of builds to keep for this branch：输入5。Only keep builds that were successful：勾选（仅保留成功构建）。
再点击 “Add Branch Rule”，配置其他分支规则：Branch Name：输入.*（正则表达式，匹配所有分支）。Max # of builds to keep for this branch：输入2。
- Disk Space Trigger（磁盘空间触发）：
勾选Enable disk space trigger，设置：Free disk space threshold：输入20（表示“剩余磁盘空间 < 20% 时触发清理”）。- 触发时的清理规则：可选择“删除所有超过 1 天的构建”等（根据需求细化）。
- General Settings（通用设置）：
步骤 4：保存配置
点击页面底部 “保存” 按钮，插件配置生效。
效果：
main分支仅保留最近 5 次成功构建；- 其他分支仅保留最近 2 次构建；
- 当 Jenkins 所在磁盘剩余空间 < 20% 时，自动触发额外清理逻辑。
五、总结与最佳实践
- 优先用自带功能：若需求是“简单的数量/天数保留”，直接用 Jenkins 自带功能，无需额外插件，稳定且易维护。
- 插件用于复杂场景：当需要“按状态、分支、磁盘空间等多维度控制”时，再安装
Discard Old Build插件，发挥其灵活性。 - 定期Review：无论用哪种方案，建议每月检查 Jenkins 工作空间和构建历史，确保清理策略符合实际存储需求。
通过本文的对比和实操，你可以根据项目场景，精准选择构建清理方案，既保证历史可追溯，又能有效控制磁盘占用～
