如何为Jenkins所有流水线创建通用post状态通知方法

你碰到的调用位置问题本质是声明式流水线的语法限制：success、failure、unstable这类条件块是post段的专属语法结构，不是普通的可执行步骤，既不能在stage的steps块里调用，也不能在没有post上下文包裹的位置直接执行，这也是你之前直接调用返回这类块的方法会报语法错误的原因。

以下两种写法都适配共享库复用的场景，根据你的流水线结构选择即可：

方案1：封装完整post逻辑（推荐，业务流水线侵入性最低） #

直接在共享库中编写返回完整post配置闭包的方法，在流水线顶层post段直接调用即可，不需要手动传入currentBuild.currentResult，post段会自动匹配构建状态执行对应通知逻辑。
共享库方法示例（存放路径：vars/sendBuildNotify.groovy）：

def call() {
    return {
        success {
            mattermostSend(
                color: '#2EB67D',
                message: "✅ 构建成功 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER} | 执行人: ${env.BUILD_USER ?: '系统触发'}\n构建地址: ${env.BUILD_URL}"
            )
        }
        failure {
            mattermostSend(
                color: '#E01E5A',
                message: "❌ 构建失败 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER} | 执行人: ${env.BUILD_USER ?: '系统触发'}\n构建地址: ${env.BUILD_URL}\n请相关负责人及时排查问题"
            )
        }
        unstable {
            mattermostSend(
                color: '#ECB22E',
                message: "⚠️ 构建不稳定 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER} | 执行人: ${env.BUILD_USER ?: '系统触发'}\n构建地址: ${env.BUILD_URL}"
            )
        }
        aborted {
            mattermostSend(
                color: '#808080',
                message: "⏹️ 构建已中止 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER} | 执行人: ${env.BUILD_USER ?: '系统触发'}\n构建地址: ${env.BUILD_URL}"
            )
        }
    }
}

业务流水线中的调用位置：直接放在顶层pipeline的post段内即可。

pipeline {
    agent any
    stages {
        stage('业务构建步骤') {
            steps {
                // 原有业务逻辑
            }
        }
    }
    post {
        always {
            // 原有全局清理逻辑可保留
        }
        // 直接调用封装好的通知方法
        sendBuildNotify()
    }
}

方案2：基于状态判断的通用通知方法（适配灵活场景） #

如果你的流水线混用了脚本式语法，或者需要在单个stage维度发送状态通知，可以封装基于传入状态判断的普通方法，统一在post.always块中调用。
共享库方法示例（存放路径：vars/sendMattermostByResult.groovy）：

def call(String buildResult) {
    def notifyConfig = [
        'SUCCESS': [
            color: '#2EB67D',
            content: "✅ 构建成功 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER}"
        ],
        'FAILURE': [
            color: '#E01E5A',
            content: "❌ 构建失败 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER}"
        ],
        'UNSTABLE': [
            color: '#ECB22E',
            content: "⚠️ 构建不稳定 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER}"
        ],
        'ABORTED': [
            color: '#808080',
            content: "⏹️ 构建已中止 | 项目: ${env.JOB_NAME} | 构建号: ${env.BUILD_NUMBER}"
        ]
    ]
    def currentConfig = notifyConfig[buildResult]
    if (currentConfig) {
        mattermostSend(
            color: currentConfig.color,
            message: "${currentConfig.content}\n构建地址: ${env.BUILD_URL}"
        )
    }
}

调用方式：不管是顶层post还是单个stage的post，都可以在always块中传入当前构建结果调用：

// 顶层post调用
post {
    always {
        sendMattermostByResult(currentBuild.currentResult)
    }
}

// 单个stage级别post调用
stage('自动化测试') {
    steps {
        // 测试逻辑
    }
    post {
        always {
            sendMattermostByResult(currentBuild.currentResult)
        }
    }
}

• 不要尝试在stage的steps块里直接调用返回success/failure块的方法，这类条件块不属于可执行步骤范畴，只能在post段的上下文中被解析
• 如果共享库方法访问currentBuild、env等全局变量时报错，可以在方法调用时显式传入对应变量，或者在共享库初始化阶段绑定流水线上下文
• 通知逻辑可以做参数扩展，比如支持传入业务线标识、自定义通知接收人、@规则等，一套逻辑就能覆盖3条业务线的差异化需求，不需要重复开发

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