[ English | English (United Kingdom) | 中文 (简体, 中国) | Indonesia | 한국어 (대한민국) | español (México) | Deutsch ]
Menggunakan Elastic Recheck¶
Catatan
Bagian ini menganggap Anda telah menyelesaikan Memeriksa Status di Zuul
Memungkinkan Anda untuk:
Tingkatkan pengujian otomatis yang dilakukan komunitas pada setiap patch yang dikirimkan ke gerrit
Laporkan bug berulang sehingga Anda tidak perlu 'recheck' secara manual
Apa yang harus dilakukan jika pekerjaan uji gagal¶
Ketika Anda mengirimkan patch ke gerrit dan zuul mengembalikan hasil tes untuk pekerjaan yang dijalankannya, terkadang salah satu dari tes itu gagal. Sebagian besar waktu ini menunjukkan ada masalah dengan perubahan yang Anda usulkan dan tes menangkapnya. Kadang-kadang uji coba mungkin telah tersandung bug yang sudah ada sebelumnya di OpenStack. Selain itu, beberapa kali infrastruktur untuk menjalankan tes mungkin mengalami kegagalan. Untuk mengetahuinya, Anda harus selalu melihat log dari pekerjaan yang gagal untuk memahami apa yang terjadi.
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.
