您的分支说明符似乎是正确的（refs/heads/master或*/master）。但是，请确保没有拼写错误或多余的空格。
而且master分支中的Jenkinsfile不应该有任何可能覆盖分支说明符的配置。
作为测试/解决方案：要在Jenkinsfile中实现检查，如果不是master分支，则将退出管道，您可以在管道脚本的开头添加条件：

pipeline {
    agent any
    stages {
        stage('Precheck') {
            steps {
                script {
                    if(env.BRANCH_NAME != 'master') {
                        currentBuild.result = 'ABORTED'
                        error('Building on master branch only')
                    }
                }
            }
        }
        // rest of your pipeline
    }
}

字符串
GitHub推送到refs/tags/1.6.0仍然导致管道执行。
转到GitHub存储库的设置，检查Jenkins服务器的webhook配置，并确保webhook设置为仅触发"push"事件，而不是"tag push"事件。
另外，修改你的Jenkinsfile来明确检查ref是一个标签还是一个分支。如果是一个标签，你可以中止构建。

pipeline {
    agent any
    stages {
        stage('Precheck') {
            steps {
                script {
                    if(env.GIT_BRANCH.startsWith('refs/tags/')) {
                        currentBuild.result = 'ABORTED'
                        error('Ignoring tag push')
                    }
                }
            }
        }
        // rest of your pipeline
    }
}

型
我注意到的是，对于行为正确的构建（不在非主推送上执行），Jenkins日志显示了以下内容
在发生故障的管道中，日志条目[FINEST] lastBuild is null和[FINEST] No match found in getLastBuild for sha1...表明Jenkins无法将传入的提交SHA与管道历史中以前的任何构建相关联。
这导致Jenkins将每次推送都视为新的更改，从而触发构建。
确保在Jenkins中正确配置了SCM轮询。它应该准确地反映您所针对的存储库和分支。
仔细检查您的Jenkins文件和管道配置，以确定工作管道和故障管道之间的任何差异，特别是SCM的设置方式。
另外，请验证日志中提到的SHA1是否对应于存储库的master分支中的提交。如果它不是来自master，则可能表明Jenkins错误地处理了来自其他分支或标签的事件。
检查故障管道的构建历史。如果Jenkins维护构建历史或将构建与特定SHA1关联的方式存在问题，这可能会导致您遇到的问题。