TeamCity配置ESLint警告数增加触发构建失败未生效问题排查

DevOps 小满

2026-8-25

问题描述

我在TeamCity 2019.2中配置了运行如下脚本的构建步骤：

"teamcity:eslint": "eslint src/**/*.{ts,tsx} --format ./node_modules/eslint-teamcity/index.js --max-warnings 0"

该步骤使用eslint-teamcity格式化代码检查的错误/警告结果，package.json配置如下：

"eslint-teamcity": {
    "reporter": "inspections",
    "report-name": "ESLint Violations",
    "error-statistics-name": "ESLint Error Count",
    "warning-statistics-name": "ESLint Warning Count"
  },

我创建了含2个ESLint警告的测试master分支，TeamCity的Inspections模块已显示这些警告，随后设置了如下失败条件：

failOnMetricChange {
            metric = BuildFailureOnMetric.MetricType.INSPECTION_WARN_COUNT
            units = BuildFailureOnMetric.MetricUnit.DEFAULT_UNIT
            comparison = BuildFailureOnMetric.MetricComparison.MORE
            compareTo = build {
                buildRule = buildWithTag {
                    tag = "test-master"
                }
            }
            stopBuildOnFailure = true
        }

测试时我创建了含3或4个ESLint警告的分支并提交，但警告数增加后构建并未触发失败，不符合预期。不清楚TeamCity存储该检查警告计数的位置，也不确定是否遗漏配置，需要排查帮助。

排查方案

确认基准构建的自定义统计项状态
找到标记为test-master的构建，进入构建结果→统计数据，查看是否存在ESLint Warning Count这个自定义统计项，同时确认其数值是否为2。如果该统计项不存在，说明eslint-teamcity的报告未被TeamCity正确解析为统计指标，后续失败条件无法触发。

修正失败条件的指标类型
当前使用的INSPECTION_WARN_COUNT是TeamCity内置的总检查警告数，而你通过eslint-teamcity定义了自定义统计项ESLint Warning Count，两者并非同一指标。需要将失败条件改为针对自定义统计项的逻辑，示例配置如下：

failOnMetricChange {
    metric = BuildFailureOnMetric.MetricType.CUSTOM
    metricKey = "ESLint Warning Count"
    units = BuildFailureOnMetric.MetricUnit.DEFAULT_UNIT
    comparison = BuildFailureOnMetric.MetricComparison.MORE
    compareTo = build {
        buildRule = buildWithTag {
            tag = "test-master"
        }
    }
    stopBuildOnFailure = true
}

验证eslint报告的输出日志
进入构建的日志标签页，搜索teamcity关键词，确认是否存在类似##teamcity[buildStatisticValue key='ESLint Warning Count' value='3']的输出行。如果没有这类输出，说明eslint-teamcity的依赖未正确安装、脚本路径有误，或者配置未生效，需要重新检查package.json的配置和构建脚本的执行逻辑。
配置项目自定义统计项
进入项目配置→统计数据页面，手动添加ESLint Warning Count作为自定义统计指标，类型选择整数。若未手动配置，TeamCity可能不会持久化该统计项，导致无法用于失败条件的对比。
确认基准构建的可访问性
确保标记为test-master的构建属于当前项目，且当前构建有权限读取该基准构建的统计数据。如果基准构建属于其他分支或项目，需要调整buildRule的匹配规则。

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