Jenkins 仅在推送到 master 时运行流水线

您的分支说明符似乎是正确的（或）。但是，请确保没有错别字或多余的空格。
分支中的 Jenkinsfile 不应具有任何可能覆盖分支说明符的配置。refs/heads/master*/mastermaster

作为测试/解决方法：要在 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 Push 到 refs/tags/1.6.0 仍然导致管道执行。

转到 GitHub 存储库的设置，检查 Jenkins 服务器的 Webhook 配置，并确保将 Webhook 设置为仅针对“推送”事件触发，而不针对“标记推送”事件触发。

此外，修改 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 日志显示以下内容

在出现故障的管道中，日志条目表明 Jenkins 无法将传入的提交 SHA 与管道历史记录中的任何先前版本相关联。
这导致 Jenkins 将每一次推送都视为新的更改，从而触发构建。[FINEST] lastBuild is null[FINEST] No match found in getLastBuild for sha1...

确保在 Jenkins 中正确配置了 SCM 轮询。它应该准确地反映你所针对的存储库和分支。
仔细检查您的 Jenkinsfile 和流水线配置，了解工作流水线和故障流水线之间的任何差异，尤其是在 SCM 的设置方式上。

此外，请验证日志中提到的 SHA1 是否与存储库分支中的提交相对应。如果不是来自 ，则可能表示 Jenkins 错误地处理了来自其他分支或标记的事件。mastermaster

检查故障管道的生成历史记录。如果 Jenkins 维护构建历史记录或将构建与特定 SHA1 相关联的方式存在问题，这可能会导致您遇到的问题。