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

检查Zuul中的状态

备注

本节假设您已完成 使用Gerrit.

本部分允许您：

  • 在Zuul测试时监控您的补丁

  • 了解OpenStack使用的底层基础设施和gating processes

什么是 Zuul

Zuul是由OpenStack基础架构团队编写和运行的工具，用于管理正在运行的连续基础架构作业。 它为项目提供了一种定义将在每个提议的提交上运行的测试作业的方法。 这些测试需要通过才能合并任何提议的补丁。

当您将补丁推送到gerrit时，zuul将自动触发作业以验证补丁功能是否正确。

跟踪Zuul状态页面中的变更

您可以随时访问以下网址查看这些作业的状态：https：//zuul.openstack.org/

../_images/zuul_status.png

这将显示当前在zuul中运行的所有作业的状态。 您可以通过单击补丁的方框来展开在任何补丁上运行的作业。

../_images/zuul_patch.png

要在zuul中找到您的特定补丁，您可以使用搜索栏并搜索补丁号。 然后，这将过滤显示的内容到该补丁：

../_images/zuul_status_searchbar.png

Why do changes go first in the check queue?

The OpenStack project uses what’s called a clean check approach. This is designed to keep flaky changes out of the gate. A change always needs to pass the check before it enters the gate. If it fails in the gate, it re-enters the check pipeline.

  • If your change fails in the gate, then there is an increased chance it is introducing non-deterministic failure behavior. Forcing it to go through check again helps make that more apparent.

  • This avoids approving changes that have no hope of ever passing due to pep8 or other trivial errors.

  • It also helps with approving changes that had been sitting around with a 6-month-old passing check.

Changes in the gate pipeline are prioritized but also serialized. If a change fails, all tests for changes behind that failing change have to be restarted. If restarts after restarts happen, then resources are never freed up for the check pipeline.

Therefore, having a stable gate pipeline is crucial and the clean check requirement will help with the stable jobs.