目录
■其它 === 1.cleanWs是jenkins的内置命令吗，如何使用
1. 安装 Workspace Cleanup Plugin
■其它 === 3.jenkins pipeline 中的post是什么
■其它 === 4.介绍一下Jenkins的目录 /var/jenkins_home/workspace/
■其它 === 5.docker 启动时，使用rm参数的作用
===
■模板
pipeline {
agent any
options { ... }
parameters { ... }
environment { ... }
triggers { ... }
tools { ... }
stages {
stage('Stage 1') {
when { ... }
agent { ... }
environment { ... }
steps { ... }
}
stage('Stage 2') {
parallel { ... }
}
}
post { ... }
}===
■Jenkins的Pipline中有哪些区块
在 Jenkins 声明式 Pipeline 中，核心结构由多个区块（Section）组成，每个区块负责不同的功能。以下是完整的区块分类及其作用：
1. pipeline（顶层区块）
作用：定义整个 Pipeline 的入口，所有其他区块必须包含在
pipeline内。示例：
pipeline { // 其他区块在此定义... }
2. agent（执行节点）
作用：指定 Pipeline 在哪个 Jenkins 节点（或容器）上运行。
常见选项：
any: 任意可用节点。none: 不全局指定节点（需在每个stage中单独定义）。label 'linux': 在标签为linux的节点上运行。docker: 在 Docker 容器中运行（需指定镜像）。
示例：
agent { docker { image 'maven:3.8.4' // 使用 Maven 容器 args '-v /tmp:/tmp' // 挂载目录 } }
3. stages（阶段集合）
作用：包裹所有具体的阶段（
stage），是 Pipeline 的核心逻辑部分。示例：
stages { stage('Build') { ... } stage('Test') { ... } stage('Deploy') { ... } }
4. stage（单个阶段）
作用：定义 Pipeline 中的一个逻辑步骤（如构建、测试、部署）。
必须包含：至少一个
steps或parallel区块。示例：
stage('Build') { steps { sh 'mvn clean package' } }
5. steps（具体步骤）
作用：在
stage中定义具体的操作（如执行 Shell 命令、调用插件）。常用命令：
sh: 执行 Linux Shell 命令。bat: 执行 Windows Batch 命令。script: 嵌入 Groovy 脚本（用于复杂逻辑）。
示例：
steps { sh 'echo "Hello Jenkins!"' script { def version = '1.0.0' echo "Building version: ${version}" } }
6. post（后置处理）
作用：根据 Pipeline 的执行结果（成功、失败等）触发后置操作。
条件块：
always: 始终执行。success: 仅成功时执行。failure: 仅失败时执行。aborted: 被中止时执行。
示例：
post { always { cleanWs() // 清理工作区 } failure { slackSend message: '构建失败!' } }
7. environment（环境变量）
作用：定义全局或阶段级的环境变量（如密钥、路径）。
示例：
environment { // 直接定义变量 APP_VERSION = '1.0.0' // 引用 Jenkins 凭据 AWS_ACCESS_KEY = credentials('aws-access-key') }
8. parameters（参数化构建）
作用：定义用户输入的参数（如字符串、选项、文件）。
常见类型：
string: 字符串参数。choice: 下拉选项。booleanParam: 布尔值。file: 文件上传。
示例：
parameters { string(name: 'DEPLOY_ENV', defaultValue: 'dev', description: '部署环境') choice(name: 'REGION', choices: ['us-east', 'eu-central'], description: 'AWS 区域') }
9. options（Pipeline 配置选项）
作用：配置 Pipeline 的全局行为（如超时时间、重试策略）。
常用选项：
timeout(time: 30, unit: 'MINUTES'): 设置超时时间。retry(3): 失败时重试 3 次。disableConcurrentBuilds(): 禁止并行执行。
示例：
options { timeout(time: 1, unit: 'HOURS') disableConcurrentBuilds() }
10. triggers（触发条件）
作用：定义 Pipeline 的触发方式（如定时触发、SCM 变更触发）。
常见触发器：
cron('H */4 * * *'): 定时触发（每 4 小时）。pollSCM('H */5 * * *'): 轮询 SCM 变更。upstream(upstreamProjects: 'job1,job2'): 上游任务触发。
示例：
triggers { cron('H 2 * * *') // 每天凌晨 2 点触发 }
11. tools（工具路径配置）
作用：指定构建工具（如 JDK、Maven）的路径（需提前在 Jenkins 全局配置中定义）。
示例：
tools { maven 'Maven-3.8.4' // 使用全局配置的 Maven 工具 jdk 'JDK-11' }
12. input（用户交互）
作用：暂停 Pipeline 并等待用户输入（如确认部署）。
示例：
stage('Deploy to Prod') { steps { input(message: '确认部署到生产环境？', ok: '确认') } }
13. when（条件执行）
作用：控制某个
stage是否执行（基于条件判断）。常见条件：
branch 'master': 仅在master分支执行。expression { return params.DEPLOY_ENV == 'prod' }: 根据参数值判断。
示例：
stage('Deploy') { when { branch 'master' expression { params.DEPLOY_ENV == 'prod' } } steps { ... } }
14. parallel（并行执行）
作用：并行运行多个
stage（加速构建）。示例：
stage('Test') { parallel { stage('Unit Test') { steps { sh 'mvn test' } } stage('Integration Test') { steps { sh 'mvn verify' } } } }
■其它 === 1.cleanWs是jenkins的内置命令吗，如何使用
cleanWs 不是 Jenkins 的内置命令，它是由 Workspace Cleanup Plugin（工作区清理插件）提供的功能。该插件需要单独安装，但因其强大的灵活性（如按条件清理、排除文件等），在 Jenkins 实践中被广泛使用。
1. 安装 Workspace Cleanup Plugin
步骤：
进入 Jenkins 控制台 → Manage Jenkins → Plugins → Available plugins → 搜索Workspace Cleanup→ 安装并重启 Jenkins。
2. cleanWs 的核心用法
基本语法
cleanWs(
deleteDirs: Boolean, // 是否删除子目录（默认 true）
patterns: [[pattern: String, type: String]], // 排除或包含的文件模式
cleanWhenSuccess: Boolean, // 构建成功时清理（默认 true）
cleanWhenAborted: Boolean, // 构建中止时清理（默认 true）
cleanWhenFailure: Boolean, // 构建失败时清理（默认 true）
cleanWhenUnstable: Boolean // 构建不稳定时清理（默认 true）
)常用场景示例
(1) 简单清理（清空所有文件）
steps {
cleanWs() // 清空工作区所有内容
}(2) 排除指定文件/目录
steps {
cleanWs(
patterns: [
[pattern: 'logs/**', type: 'EXCLUDE'], // 保留 logs 目录
[pattern: '*.config', type: 'EXCLUDE'] // 保留所有 .config 文件
]
)
}(3) 仅在构建失败时清理
steps {
cleanWs(
cleanWhenSuccess: false, // 成功时不清理
cleanWhenFailure: true // 仅失败时清理
)
}3. 在 Pipeline 中的使用
声明式 Pipeline
groovy
复制
下载
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package'
}
}
}
post {
always {
cleanWs(
patterns: [
[pattern: 'target/*.jar', type: 'EXCLUDE'] // 保留构建产物
]
)
}
}
}
脚本式 Pipeline
node {
try {
stage('Build') {
sh 'mvn clean package'
}
} finally {
cleanWs() // 无论结果如何，清理工作区
}
}4. cleanWs vs deleteDir()
| 特性 | cleanWs |
deleteDir() |
|---|---|---|
| 来源 | Workspace Cleanup 插件 | Jenkins 内置 |
| 灵活性 | 支持按条件清理、排除文件 | 只能删除整个目录 |
| 适用场景 | 需要精细控制清理内容的场景 | 快速清空目录 |
| 依赖 | 需安装插件 | 无需插件 |
5. 注意事项
路径问题：
cleanWs默认清理当前工作目录（WORKSPACE），确保操作目录正确。权限问题：
Jenkins 进程需要有工作目录的读写权限。文件占用：
若文件被其他进程锁定（如正在运行的 JAR 文件），可能导致清理失败。插件兼容性：
确保插件版本与 Jenkins 兼容（插件文档会注明支持的版本）。
总结
需要灵活清理工作区时：优先使用
cleanWs，通过patterns参数控制保留或删除的文件。简单快速清理时：直接使用内置的
deleteDir()。关键场景：建议在
post { always { ... } }中清理工作区，避免残留文件占用磁盘空间。
■其它 === 2.如何查看jenkins中已经定义的节点
1. 通过 Web 界面查看
(1) 进入节点管理页面
打开 Jenkins 主页 → 点击左侧菜单的
Manage Jenkins（管理 Jenkins）。在管理页面中找到
Nodes（节点）或Manage Nodes and Clouds（管理节点和云），点击进入。
(2) 查看节点列表
页面会列出所有已定义的节点，包括：
Built-In Node（主节点，即 Jenkins 控制器）。其他代理节点（如
linux-agent、windows-agent等）。
(3) 查看节点详情
点击节点名称（如
linux-agent）→ 进入节点详情页，可查看：节点状态（在线/离线）。
标签（Labels）。
工作目录路径（Remote root directory）。
启动方式（Launch method）。
系统信息（如操作系统、Java 版本）。
2. 通过命令行查看（需管理员权限）
(1) 使用 Jenkins CLI
Jenkins 提供了命令行工具（CLI），可通过以下命令列出所有节点：
java -jar jenkins-cli.jar -s http://your-jenkins-url list-nodes(2) 使用 Groovy 脚本
在 Jenkins 的 Script Console（脚本控制台）中执行以下脚本：
Jenkins.instance.nodes.each { node ->
println "节点名称: ${node.displayName}"
println "标签: ${node.labelString}"
println "工作目录: ${node.remoteFS}"
println "状态: ${node.toComputer().online ? '在线' : '离线'}"
println "------"
}3. 通过 API 查看
调用 Jenkins REST API 获取节点列表（需权限）：
curl -u username:api-token http://your-jenkins-url/computer/api/json返回的 JSON 数据中会包含所有节点的详细信息。
关键信息说明
| 字段 | 说明 |
|---|---|
| 节点名称 | 节点的唯一标识符（如 linux-agent）。 |
| 标签 | 节点的分类标记（如 linux、docker），用于任务调度。 |
| 工作目录 | 节点的工作路径（如 /var/jenkins/workspace）。 |
| 执行器数量 | 节点可同时运行的任务数（默认为 1）。 |
| 状态 | 节点是否在线（Online/Offline）。 |
■其它 === 3.jenkins pipeline 中的post是什么
post 的核心特性
条件触发：通过预定义的条件关键字（如
always、success、failure），指定不同执行结果下需要运行的步骤。执行顺序：
post中的操作会在所有stages执行完毕后运行。灵活性：可以同时定义多个条件块，每个块内的步骤独立执行。
post 的条件关键字
以下是常用的条件类型：
| 条件关键字 | 触发条件 |
|---|---|
always |
无论 Pipeline 结果如何，始终执行（最常用，例如清理工作目录） |
success |
仅当 Pipeline 全部阶段成功完成时执行（例如发送成功通知） |
failure |
仅当 Pipeline 任何阶段失败时执行（例如发送失败报警或记录日志） |
aborted |
当 Pipeline 被手动中止时执行（例如通知构建被取消） |
unstable |
当 Pipeline 标记为 unstable 时执行（例如测试通过但覆盖率不足） |
changed |
当 Pipeline 状态与上一次不同时执行（例如从失败恢复为成功时通知） |
post 的语法示例（声明式 Pipeline）
pipeline {
agent any
stages {
// 主要构建阶段...
stage('Build') {
steps {
sh 'mvn clean package'
}
}
}
// 后置操作
post {
// 无论结果如何，始终清理工作目录
always {
deleteDir()
}
// 构建成功时发送通知
success {
slackSend channel: '#builds', message: '构建成功!'
}
// 构建失败时发送邮件
failure {
mail to: 'team@example.com', subject: '构建失败', body: '请检查日志!'
}
// 构建被中止时记录日志
aborted {
echo 'Pipeline 被用户中止'
}
}
}post 的常见用途
清理工作目录
post { always { deleteDir() // 清空工作区 } }发送通知
post { failure { slackSend channel: '#alerts', message: '构建失败: ${BUILD_URL}' } }归档构建产物
post { success { archiveArtifacts artifacts: 'target/*.jar', fingerprint: true } }生成测试报告
post { always { junit 'target/surefire-reports/*.xml' // 记录单元测试结果 } }
注意事项
仅适用于声明式 Pipeline
post是声明式 Pipeline 的语法特性，脚本式 Pipeline 需通过try-catch-finally实现类似逻辑。条件块的执行顺序
Jenkins 会按post中定义的顺序执行条件块，但每个条件块是否执行仍取决于其触发条件。灵活组合条件
可以通过嵌套逻辑实现更复杂的条件判断（例如：仅在失败且不是中止时触发）。
脚本式 Pipeline 的替代方案
脚本式 Pipeline 中没有原生 post 块，但可通过 try-catch-finally 模拟类似行为：
node {
try {
stage('Build') {
// 构建步骤...
}
} catch (err) {
// 失败处理
echo "构建失败: ${err}"
} finally {
// 始终执行的清理操作（类似 post { always }）
deleteDir()
}
}总结
post 是 Jenkins Pipeline 中管理后置操作的核心机制，能帮助你在不同构建结果下自动执行关键任务（如清理、通知、归档）。掌握它的用法可以让你的 Pipeline 更健壮、更易维护！
===
■其它 === 4.介绍一下Jenkins的目录 /var/jenkins_home/workspace/
在 Jenkins 中，/var/jenkins_home/workspace/ 是 工作目录（JENKINS_HOME） 下的一个核心子目录，用于存储每个项目的源代码和构建过程中生成的临时文件。
每个 Job 的目录名与 Jenkins 中定义的 任务名称完全一致（包括大小写敏感）。
例如，一个名为 my-web-app 的 Job，其工作区目录路径为：
/var/jenkins_home/workspace/my-web-app/
/var/jenkins_home/workspace/my-java-app/
├── src/ # 从版本控制库（如 Git）拉取的源代码
├── target/ # 构建生成的输出（如编译后的 JAR 文件）
├── pom.xml # Maven 构建配置文件
├── Jenkinsfile # Pipeline 脚本（如果是流水线任务）
├── logs/ # 构建过程中生成的日志文件
└── test-reports/ # 单元测试或集成测试报告（如 JUnit XML）
==
■其它 === 5.docker 启动时，使用rm参数的作用
在 Docker 中，使用 --rm 参数的作用是 在容器停止运行后自动删除该容器。这是 Docker 用于简化容器生命周期管理的常用参数，尤其适用于临时性任务或测试场景。
自动清理：当容器退出（无论是正常终止还是异常退出）时，自动删除容器。
避免残留：防止因手动操作遗漏导致系统中堆积大量已停止的容器，节省磁盘空间。
■其它 === 6.docker 参数介绍
Docker命令_各种参数简介（run、v、rm、-w、-u、-e）_docker -e-CSDN博客
■其它 === 7.docker 参数 it 的 英文
-i / --interactive // / ˌɪntərˈæktɪv / 交互式的，人机对话的；相互交流的，互动的
Keep STDIN open even if not attached (保持标准输入开放，允许交互操作).
用途：允许用户向容器发送输入（如键盘输入）。
-t / --tty
Allocate a pseudo-TTY (分配一个伪终端).
用途：使容器内的命令行界面（如 bash）支持终端功能（如显示提示符、响应快捷键）。
TTY的英文全称是Teletypewriter。 // teletype [ˈtɛlɪtaɪp] 电传打字机;电传打字电报;
・历史背景：TTY 最初指物理的电传打字机，是一种通过键盘输入、打印机输出的早期终端设备，用于与计算机交互。
・现代意义：在当代操作系统中，TTY 演化为终端（Terminal）的抽象概念，代表用户与系统内核通信的接口
・物理终端：直接连接计算机的控制台（如 /dev/tty1）。
・伪终端（PTY）：软件模拟的终端（如 SSH 会话或终端模拟器中的 /dev/pts/0） // pseudo / ˈsuːdəʊ; ˈsjuːdəʊ / 假的，伪装的
・容器技术：Docker 的 -t 参数（即 --tty）会为容器分配伪终端，使交互式命令（如 bash）能正常使用终端功能。
====
===