ການເລີ່ມຕົ້ນນຳໃຊ້ລະບົບ CI

ການທົດສອບໃນ Fedora

ມັນຂ້ອນຂ້າງງ່າຍທີ່ຈະເລີ່ມທົດສອບ Fedora artifacts (Koji builds, Bodhi updates, ແລະ ອື່ນໆ) ແລະ ສົ່ງຜົນການທົດສອບກັບຄືນ ເພື່ອໃຫ້ສາມາດນຳໃຊ້ເຂົ້າໃນການກັ່ນຕອງ (gating) ໃນພາຍຫຼັງ — ເຊັ່ນ: ການຕັດສິນໃຈວ່າ artifact ທີ່ຖືກທົດສອບນັ້ນຄວນຈະໄດ້ຮັບການອະນຸມັດໃຫ້ຜ່ານຫຼືບໍ່.

ໃນນີ້ພວກເຮົາຈະອະທິບາຍຂັ້ນຕອນທີ່ຈຳເປັນເພື່ອເພີ່ມລະບົບ CI ໃໝ່.

ລະບົບ CI (ທີ່ເໝາະສົມ) ແມ່ນຫຍັງ?

ເພື່ອໃຫ້ມີຂັ້ນຕອນການເຮັດວຽກ ແລະ ປະສົບການຜູ້ໃຊ້ທີ່ດີ, ນີ້ແມ່ນບາງດ້ານຂອງລະບົບ CI ທີ່ໄດ້ຮັບການພິສູດແລ້ວວ່າປະສົບຜົນສຳເລັດ:

  • ການທົດສອບມີຄວາມເຊື່ອຖືໄດ້ (ມີອັດຕາການລາຍງານຜິດພາດຕໍ່າ) ແລະ ກວມເອົາເນື້ອໃນທີ່ສຳຄັນ

  • ການທົດສອບສາມາດມີສ່ວນຮ່ວມໄດ້ (ຮູບແບບໂອເພັນຊອດ) ແລະ ຄວນມີລັກສະນະຄ້າຍຄືກັບການທົດສອບອື່ນໆ, ເຊັ່ນ: ການໃຊ້ໂຄງຮ່າງ ຫຼື ພາສາທີ່ເປັນມາດຕະຖານ

  • ຜົນການທົດສອບ ຫຼື ການແຈ້ງເຕືອນແມ່ນເຂົ້າໃຈງ່າຍ ແລະ ຊ່ວຍໃຫ້ລະບຸຂໍ້ຜິດພາດໄດ້ໄວ

  • ການທົດສອບສາມາດເຮັດຄືນໃໝ່ໄດ້, ຖ້າຈຳເປັນກໍໃຫ້ເກັບຮັກສາ artifact ຈາກການທົດສອບໄວ້ໃຫ້ຜູ້ໃຊ້ງານ, ເຊັ່ນ: virtual machine images

ເວົ້າສັ້ນໆກໍຄື, ຜົນການທົດສອບຄວນຈະສາມາດນຳໄປຈັດການຕໍ່ໄດ້ທັນທີ! ໃນຖານະນັກພັດທະນາ, ຂ້ອຍຈຳເປັນຕ້ອງຕັດສິນໃຈໃຫ້ໄວວ່າ ບັນຫາເກີດຈາກຕົວທົດສອບ ຫຼື ເກີດຈາກໂຄດ, ແລ້ວຈຶ່ງແກ້ໄຂບັນຫານັ້ນ.

ການທົດສອບ ແລະ ການກັ່ນຕອງການ Build

ຂັ້ນຕອນການເຮັດວຽກຂອງການກັ່ນຕອງ

ໃນລະດັບສູງສຸດ, ຂັ້ນຕອນການເຮັດວຽກຂອງການກັ່ນຕອງ ປະກອບມີຂັ້ນຕອນດັ່ງຕໍ່ໄປນີ້:

  • Submit build(s) of one or more package(s) (Koji), and an update containing those builds (Bodhi)

  • ກະຕຸ້ນລະບົບ CI ເພື່ອເລີ່ມການທົດສອບ (Fedora CI, ລະບົບ CI ຂອງເຈົ້າ, ແລະ ອື່ນໆ)

  • ຮ່ວບຮວມຜົນການທົດສອບຈາກລະບົບ CI (ResultsDB)

  • ເຮັດການຕັດສິນໃຈ (Greenwave)

  • ຖ້າຜົນການຕັດສິນໃຈແມ່ນ "ຜ່ານ", ກໍຈະໃຫ້ການ build ນັ້ນຜ່ານການກັ່ນຕອງໄປຫາບ່ອນເກັບຂໍ້ມູນຫຼັກ (Bodhi)

ຂໍ້ຄວາມການກັ່ນຕອງ

Gating process is implemented as a set of services which interact with each other via message bus (Fedora Messaging).

ດັ່ງນັ້ນ, ເພື່ອເພີ່ມພາກສ່ວນໃດໜຶ່ງ (ຕົວຢ່າງ: ລະບົບ CI) ເຂົ້າໃນຂະບວນການ, ເຈົ້າຈຳເປັນຕ້ອງເລີ່ມການຮັບ ແລະ ສົ່ງຂໍ້ຄວາມຜ່ານ FedoraMessaging.

ວິທີເພີ່ມລະບົບ CI

ລະບົບ CI ໃນ Fedora ແມ່ນໜ່ວຍງານທີ່ເຮັດວຽກເປັນເອກະລາດ ເຊິ່ງໂດຍປົກກະຕິແລ້ວຕ້ອງຈັດການກັບສິ່ງຕໍ່ໄປນີ້:

  • ການກະຕຸ້ນເມື່ອມີເຫດການໃດໜຶ່ງເກີດຂຶ້ນ

  • ການທົດສອບຕົວຈິງ

  • ການເຜີຍແຜ່ຜົນການທົດສອບ

ການກະຕຸ້ນ ແລະ ການທົດສອບ

Services in Fedora publish messages when various events occur and thus CI systems can trigger testing when for example a Bodhi update is created, or the builds in it change.

When either of those things happen, a new "koji-build-group.build.complete" message is published on the org.fedoraproject.prod.bodhi.update.status.testing.koji-build-group.build.complete topic.

The schema of these "koji-build-group.build.complete" messages is defined in the CI Messages specification.

You can design your CI system to trigger your tests in response to these messages. Some systems may have RabbitMQ listener code available for you to use (the current Fedora Messaging system is based on RabbitMQ). If you are using Jenkins you can try to follow the way the Fedora CI triggers work, e.g. the rpmdeplint trigger. If you can write the trigger code in Python, you can follow the fedora-messaging consumer documentation.

It’s of course possible to trigger testing on other types of events, not just Bodhi updates. You can find more Fedora message topics in the fedora-messaging documentation. Beware though, the list is incomplete.

ການແບ່ງປັນຜົນການທົດສອບ

CI systems should publish results to ResultsDB. This is required if you want the results to appear in the Bodhi web UI and for it to be possible to gate Bodhi updates on the results. Results should usually follow the format used by established systems like Fedora CI and openQA. In particular, for Bodhi gating to work, the 'item' for your result must be either a package NVR (in which case its 'type' must be 'koji_build') or an update ID like 'FEDORA-2026-be33882b5c' (in which case its type must be 'bodhi_update').

If your reporting code is in Python, you may find the resultsdb_conventions library a convenient helper for generating results in the expected formats for Fedora package, update or compose tests.

As well as final "results", CI systems can and likely should publish "results" that indicate test execution progress. The special 'outcomes' QUEUED and RUNNING exist for this purpose. Bodhi understands these results and displays them appropriately so people can see the current status of queued and running tests.

Publishing results to the production ResultsDB instance requires authentication. You will need to ask the Infrastructure team for credentials for this. It is a good idea to test your reporting code against a local ResultsDB instance first.

CI systems may also publish standardized CI messages so the progress of the testing can be observed and the results can be acted upon by other services in the Fedora infrastructure. There is a system that automatically forwards CI messages in certain formats to ResultsDB, so you may be able to avoid having explicit result reporting code. Note there is currently (as of 2026-07) a plan to decommission that system and stop publishing CI messages as a matter of course.

ມີຂໍ້ຄວາມສີ່ປະເພດທີ່ລະບົບ CI ຄວນຈະສົ່ງ:

  • test.queued - ເມື່ອມີ artifact (ຕົວຢ່າງ Bodhi update) ຢູ່ໃນຄິວເພື່ອລໍຖ້າການທົດສອບ

  • test.running - ເມື່ອການທົດສອບກຳລັງດຳເນີນຢູ່

  • test.complete - ເມື່ອການທົດສອບສຳເລັດແລ້ວ

  • test.error - ເມື່ອການທົດສອບບໍ່ສາມາດເລີ່ມຕົ້ນ ຫຼື ບໍ່ສາມາດສຳເລັດໄດ້ ຍ້ອນສະພາບແວດລ້ອມພາຍນອກ (ໂດຍປົກກະຕິແມ່ນຂໍ້ຜິດພາດຂອງໂຄງສ້າງພື້ນຖານ)

These messages have well-defined schemas. The schemas are part of the CI Messages specification.

For convenience, here are links to schemas for simple koji-build artifacts and fedora-update artifacts:

ຕົວລະບຸການທົດສອບ

When you send a "koji-build.test." or "fedora-update.test." message to the message bus, a result should be forwarded to ResultsDB by ci-resultsdb-listener, if the message contained the fields it expects (and the system is not explicitly excluded, as e.g. openQA is, because it does its own reporting). Later on you can refer to the stored test result in a Greenwave policy: "if test XYZ passed, let the build through the gate". Again, note this system may be dropped in future in favor of expecting CI systems to report directly to ResultsDB.

ດັ່ງນັ້ນ, ເຈົ້າຈຶ່ງຈຳເປັນຕ້ອງມີຕົວລະບຸທີ່ບໍ່ຊໍ້າກັນສຳລັບຜົນການທົດສອບ.

ຕົວລະບຸການທົດສອບສ້າງຂຶ້ນຈາກສາມສ່ວນ: namespace ຂອງການທົດສອບ, ໝວດໝູ່ການທົດສອບ ແລະ ປະເພດການທົດສອບ.

In the koji-build and fedora-update message schemas, these variables are represented by namespace, category and type fields respectively.

Namespace ຈະເປັນ ID ຂອງລະບົບ CI ຂອງເຈົ້າສະເໝີ ພ້ອມກັບຊື່ຂອງປະເພດ artifact, ຕົວຢ່າງ: fedora-ci.koji-build, ຫຼື osci.pull-request.

ໝວດໝູ່ (Category) ເຈົ້າສາມາດເລືອກໄດ້ຈາກລາຍຊື່ທີ່ກຳນົດໄວ້ແລ້ວ:

  • static-analysis

  • functional

  • integration

  • validation

Type ແມ່ນຂໍ້ຄວາມໃດໜຶ່ງທີ່ເຈົ້າສາມາດກຳນົດໄດ້ເອງ ຕາມລັກສະນະສະເພາະຂອງລະບົບ CI ຂອງເຈົ້າ.

ມັນແມ່ນຄວາມຮັບຜິດຊອບຂອງເຈົ້າ ໃນຖານະເຈົ້າຂອງລະບົບ CI ທີ່ຈະຕ້ອງຮັກສາການຕັ້ງຊື່ການທົດສອບໃຫ້ສອດຄ່ອງກັນພາຍໃຕ້ namespace ຂອງເຈົ້າ.

ຕົວລະບຸການທົດສອບຂັ້ນສຸດທ້າຍອາດຈະມີລັກສະນະດັ່ງນີ້: fedora-ci.koji-build.tier0.functional

ລິ້ງທີ່ເປັນປະໂຫຍດ

Want to help? Learn how to contribute to Fedora Docs ›