[ English | English (United Kingdom) | 中文 (简体, 中国) | Indonesia | 한국어 (대한민국) | español (México) | Deutsch ]

使用Elastic Recheck

备注

本部分假设您已完成 检查Zuul中的状态

允许您:

  • 增强社区对提交给gerrit的每个补丁所做的自动测试

  • 报告重复出现的错误，是的您无需手动’重新检查’

如果测试作业失败该怎么办

当您向gerrit提交补丁时，zuul返回其运行的测试结果，有时其中一项测试失败。 在大多数情况下，这表明您建议的更改存在问题，并且测试正在找出问题。 有时，测试运行可能会因OpenStack中潜在的预先存在的错误而跳闸。 此外，有时运行测试的基础设施可能会出现故障。 为了弄清楚这一点，您始终需要查看失败作业的日志以了解发生了什么。

A comment recheck on the patch would trigger the failed job to execute again. DO NOT just recheck the patch only to see if it fails again. CI test resources are very scarce. Read this document to know how to handle test failures

OpenSearch

For deeper investigation of related log messages across multiple builds of jobs, a community-run OpenSearch cluster is available, with both a WebUI for producing real-time graphs as well as a REST API for more programmatic analysis.

Past and Future of Elastic Recheck

At one time, there existed a service to automatically analyze indexed job logs in order to match them against curated queries for known bug signatures, and leave helpful review comments on changes when those same failures were identified in a new build. That service relied on an old suite of systems fronted by logstash.openstack.org, which ceased operation in April 2022. A recreation of that solution is in progress based on the community’s new OpenSearch backend, but is not available for general use yet.