Jenkins旧构建工作区清理配置无效，求快速清理与自动化方案

配置失效的常见原因 #

• 规则范围不匹配：若你配置的是仅清理当前构建工作区，而非历史构建数据，或者任务设置了「保留构建」规则，其优先级高于工作区清理，会导致旧构建的工作区被保留。
• 任务类型限制：Pipeline等特殊任务需在Jenkinsfile中显式添加清理逻辑，仅靠GUI配置的全局/任务级规则可能不生效。
• 权限不足：Jenkins运行用户没有目标工作区目录的删除权限，导致清理命令执行失败。
• 插件冲突：第三方工作区管理插件可能覆盖原生清理规则，导致配置失效。

为什么Jenkins空间清理比GitHub Actions/GitLab复杂 #

• 灵活性带来的复杂度：Jenkins支持自定义工作区路径、分布式多节点构建、多种任务类型，清理逻辑无法像GitHub Actions/GitLab那样标准化封装，需根据实际场景适配。
• 历史兼容性包袱：Jenkins迭代周期长，新旧版本清理逻辑存在差异，老项目沿用旧配置易出现兼容问题。
• 存储模式差异：GitHub Actions/GitLab Runner默认使用全新临时工作区，而Jenkins默认复用或保留工作区，天然需要更多手动配置管控存储。

快速清理与自动化方案 #

快速删除所有旧构建数据 #

• 批量删除历史构建：在任务的「构建历史」页面勾选所有旧构建后点击删除；若构建数量过多，可通过Jenkins脚本控制台执行以下命令：

def jobName = "你的任务名称"
def job = Jenkins.instance.getItem(jobName)
job.getBuilds().each { build ->
  build.delete()
}

• 磁盘直接清理：登录Jenkins服务器，找到工作区根目录（默认路径为${JENKINS_HOME}/workspace），执行命令批量清理旧目录：

# 删除7天前的工作区目录
find /var/lib/jenkins/workspace -type d -mtime +7 -exec rm -rf {} \;

自动化清理配置 #

• 任务级配置：在任务的「构建后操作」中添加「Delete workspace when build is done」，同时在「构建保留策略」中设置「保留最近N次构建」和「保留构建天数」，两者结合自动清理超出限制的构建及工作区。
• Pipeline任务：在Jenkinsfile中嵌入清理步骤，确保构建前后清理工作区：

pipeline {
  agent any
  stages {
    stage('Clean Workspace') {
      steps {
        cleanWs() // 清理当前工作区
      }
    }
    // 其他构建阶段
  }
  post {
    always {
      deleteDir() // 构建完成后删除工作区
    }
  }
}

• 全局配置：安装Workspace Cleanup Plugin，在全局配置中设置默认清理规则应用到所有任务；搭配Disk Usage Plugin监控磁盘占用，达到阈值时触发自动清理。

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