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

Status in Zuul prüfen

Bemerkung

Dieser Abschnitt geht davon aus, dass Sie Verwendung von Gerrit abgeschlossen haben.

In diesem Abschnitt können Sie:

  • Überwachen Sie Ihre Patches, während sie von Zuul getestet werden

  • Verstehen der zugrunde liegenden Infrastruktur und der Gating-Prozesse, die OpenStack verwendet

Was ist Zuul

Zuul ist ein vom OpenStack Infrastructure-Team geschriebenes und ausgeführtes Tool, das zur Verwaltung laufender kontinuierlicher Infrastrukturaufträge verwendet wird. Es bietet Projekten die Möglichkeit, Testaufträge zu definieren, die bei jedem vorgeschlagenen Commit ausgeführt werden. Diese Tests müssen bestanden werden, damit jeder vorgeschlagene Patch zusammengeführt werden kann.

Wenn Sie einen Patch zu gerrit schieben, löst Zuul automatisch Aufträge aus, um die korrekte Funktion des Patches zu überprüfen.

Verfolgung von Änderungen auf der Zuul-Statusseite

Sie können den Status dieser Aufträge jederzeit überprüfen, indem Sie auf https://zuul.openstack.org/ navigieren

../_images/zuul_status.png

Dies zeigt Ihnen den Status aller Aufträge, die derzeit in zuul laufen. Sie können Aufträge, die auf jedem Patch ausgeführt werden, erweitern, indem Sie auf das Kästchen für einen Patch klicken.

../_images/zuul_patch.png

Um Ihren spezifischen Patch in zuul zu finden, können Sie die Suchleiste verwenden und nach der Patch-Nummer suchen. Dies filtert dann, was genau zu diesem Patch angezeigt wird:

../_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.