ວິທີເພີ່ມການທົດສອບ STI ແບບງ່າຍໆ ສຳລັບແພັກເກັດ
ທົດສອບເປັນຄຳສັ່ງດຽວ
ວຽກງານ
ມີແພັກເກັດ somepackage, ເຊິ່ງບັນຈຸໄຟລ໌ໄບນາຣີ (binary): /usr/bin/somebinary
ວິທີທີ່ງ່າຍ ແລະ ຊັດເຈນທີ່ສຸດໃນການທົດສອບໄບນາຣີນີ້ແມ່ນການລັນ (run) ມັນ: somebinary --help ແລະ ກວດສອບສະຖານະການອອກ (exit status) ຂອງຜົນລັບ.
ຈະເພີ່ມການທົດສອບນີ້ໃຫ້ກັບແພັກເກັດໄດ້ແນວໃດ?
ໂຄງຮ່າງ (framework) [Standard Test Roles] ໃຫ້ທາງອອກສຳລັບວຽກງານນີ້. ມັນໄດ້ຮັບການຮອງຮັບຢ່າງເຕັມຮູບແບບໃນ Fedora Rawhide.
ວິທີແກ້ໄຂ
ສ້າງໄຟລ໌ tests/tests.yml ໃນ dist-git ຂອງແພັກເກັດ:
.
├── 0001-something.patch
├── somepackage.spec
├── sources
└── tests
└── tests.yml
tests.yml ແມ່ນ ansible playbook, ບ່ອນທີ່ທ່ານກຳນົດສະພາບແວດລ້ອມການທົດສອບ ແລະ ຂັ້ນຕອນໃນການລັນການທົດສອບຂອງທ່ານ.
ມີຫຼາຍຕົວເລືອກ ແລະ [ຕົວຢ່າງທີ່ມີໃຫ້], ແຕ່ໃຫ້ເຮົາມາເນັ້ນໃສ່ວຽກງານທີ່ກຳລັງເຮັດຢູ່: ພວກເຮົາຕ້ອງການລັນພຽງແຕ່ຄຳສັ່ງດຽວ.
ສຳລັບກໍລະນີນີ້ ເນື້ອໃນຂອງໄຟລ໌ຄວນເປັນດັ່ງນີ້:
- hosts: localhost
roles:
- role: standard-test-basic (1)
tags:
- classic
tests:
- simple:
dir: .
run: "somebinary --help" (2)
| 1 | ນີ້ແມ່ນ standard test role, ມັນຈະຈັດການກ່ຽວກັບສະພາບແວດລ້ອມການທົດສອບ, ການບັນທຶກລັອກ (logging), ການຈັດເກັບຜົນລັບ, ແລະ ອື່ນໆ |
| 2 | ນີ້ແມ່ນຄຳສັ່ງທົດສອບຂອງທ່ານ, ລະຫັດການອອກ (exit code) ຂອງມັນຈະເປັນຕົວບົ່ງບອກຜົນຂອງການທົດສອບ |
ສົ່ງການປ່ຽນແປງຂອງທ່ານເປັນ pull request ເພື່ອເບິ່ງຜົນການທົດສອບໃນໜ້າຕ່າງຂອງ Pagure, ຫຼື ພຸສ (push) ມັນລົງໃນ dist-git ໂດຍກົງ ແລະ ຮັບຜົນການທົດສອບໃໝ່ທຸກຄັ້ງທີ່ທ່ານບິວດ໌ (build) ແພັກເກັດໃນ Koji.
| ການທົດສອບຈະລັນໃນໂໝດ non-blocking ຈົນກວ່າທ່ານຈະກຳນົດ gating ສຳລັບມັນ. |
ການທົດສອບໃນແພັກເກັດຍ່ອຍ (subpackage)
ວຽກງານ
ມີແພັກເກັດ somepackage, ແລະ ມີຊຸດການທົດສອບແບບບູລະນາການ (integration test suite) ສຳລັບມັນ ທີ່ຖືກແພັກຢູ່ໃນແພັກເກັດ sometests ແຍກຕ່າງຫາກ, ເຊິ່ງໃຫ້ໄບນາຣີ run_some_tests ໃນ system path.
ເປົ້າໝາຍແມ່ນເພື່ອເອີ້ນໃຊ້ໄບນາຣີນີ້ ເປັນການທົດສອບສຳລັບແພັກເກັດຫຼັກ.
ວິທີແກ້ໄຂ
ຄືກັນກັບຂ້າງເທິງ, ທ່ານຈຳເປັນຕ້ອງສ້າງໄຟລ໌ກຳນົດຄ່າ tests.yml ທີ່ມີເນື້ອໃນດັ່ງນີ້:
---
- hosts: localhost
roles:
- role: standard-test-basic
tags:
- classic
required_packages:
- sometests (1)
tests:
- integration_tests: (2)
dir: .
run: run_some_tests (3)
| 1 | ແພັກເກັດເພີ່ມເຕີມທີ່ຈຳເປັນຕ້ອງໄດ້ຕິດຕັ້ງໃນສະພາບແວດລ້ອມການທົດສອບ |
| 2 | ຂໍ້ຄວາມໃດໆກໍໄດ້, ຈະຖືກໃຊ້ເປັນຕົວລະບຸສຳລັບ artifacts ແລະ ຜົນການທົດສອບ |
| 3 | ຄຳສັ່ງປະຕິບັດການທົດສອບ |
ການທົດສອບໃນຄັງເກັບພາຍນອກ (external repository)
ວຽກງານ
ບາດນີ້ ມາເບິ່ງການຕັ້ງຄ່າທີ່ຊັບຊ້ອນຂຶ້ນເລັກນ້ອຍ.
ສົມມຸດວ່າມີແພັກເກັດ somepackage ທີ່ພວກເຮົາກຳລັງຈະທົດສອບ. ມີຊຸດການທົດສອບແບບບູລະນາການສຳລັບມັນ, ເຊິ່ງ (ໜ້າເສຍດາຍ) ຍັງບໍ່ທັນໄດ້ຖືກເຮັດເປັນແພັກເກັດ ແລະ ຕັ້ງຢູ່ໃນຄັງເກັບ git ແຍກຕ່າງຫາກ https://somewhere/sometests.git. ຊຸດການທົດສອບມີການຂຶ້ນຕໍ່ກັບ (dependency) ເຄື່ອງມື sometool ບາງຢ່າງທີ່ຖືກເຮັດເປັນແພັກເກັດແລ້ວ. ແລະ ໃນຄັງເກັບການທົດສອບມີສະຄຣິບ run_some_tests ເຊິ່ງຈະເອີ້ນໃຊ້ການທົດສອບ.
ເປົ້າໝາຍແມ່ນເພື່ອເອີ້ນໃຊ້ການປະຕິບັດຊຸດການທົດສອບສຳລັບແພັກເກັດ.
ວິທີແກ້ໄຂ
ພວກເຮົາຈຳເປັນຕ້ອງສ້າງໄຟລ໌ກຳນົດຄ່າ tests.yml ທີ່ມີເນື້ອໃນດັ່ງນີ້:
---
- hosts: localhost
roles:
- role: standard-test-basic (1)
tags:
- classic
required_packages:
- sometool (2)
repositories:
- repo: "https://somewhere/sometests.git" (3)
dest: "sometests" (4)
tests:
- integration_tests: (5)
dir: "sometests" (6)
run: "run_some_tests --all" (7)
| 1 | ບົດບາດການທົດສອບພື້ນຖານແບບດຽວກັນກັບປົກກະຕິ |
| 2 | ແພັກເກັດເພີ່ມເຕີມທີ່ຈຳເປັນຕ້ອງໄດ້ຕິດຕັ້ງໃນສະພາບແວດລ້ອມການທົດສອບ |
| 3 | ເສັ້ນທາງ (path) ໄປຫາຄັງເກັບ git ທາງໄກ |
| 4 | ເສັ້ນທາງພາຍໃນເຄື່ອງ (local path) ບ່ອນທີ່ຄັງເກັບຈະຖືກດຶງອອກມາ (checked out) |
| 5 | ຂໍ້ຄວາມໃດໆກໍໄດ້, ຈະຖືກໃຊ້ເປັນຕົວລະບຸສຳລັບ artifacts ແລະ ຜົນການທົດສອບ |
| 6 | ໂຟນເດີດຽວກັນກັບໃນ <4>, ບັນຈຸຄັງເກັບພາຍນອກທີ່ຖືກດຶງອອກມາແລ້ວ |
| 7 | ຄຳສັ່ງປະຕິບັດການທົດສອບ |
ຄຳຖາມ
ຈະເຮັດແນວໃດ ຖ້າຂ້ອຍບໍ່ຕ້ອງການລັນພຽງຄຳສັ່ງດຽວ ແຕ່ຕ້ອງການລັນເປັນລຳດັບຄຳສັ່ງ?
ໃສ່ bash script ໃນໂຟນເດີ tests/scripts/ ແລະ ລັນມັນຈາກ playbook.
.
├── 0001-something.patch
├── somepackage.spec
├── sources
└── tests
├── scripts
│ └── run_tests.sh (1)
└── tests.yml
| 1 | ສະຖານະການການທົດສອບທີ່ທ່ານກຳນົດເອງ |
ກຳນົດຄ່າການທົດສອບ dist-git ເພື່ອລັນສະຄຣິບນີ້:
- hosts: localhost
roles:
- role: standard-test-basic (1)
tags:
- classic
tests:
- simple:
dir: scripts (2)
run: ./run_tests.sh (3)
| 1 | standard role ດຽວກັນ |
| 2 | ປ່ຽນໄປຫາໂຟນເດີຍ່ອຍ (ເສັ້ນທາງແມ່ນທຽບກັບໂຟນເດີ tests/) |
| 3 | ນີ້ແມ່ນສະຄຣິບການທົດສອບ, ລະຫັດການອອກຂອງມັນແມ່ນຜົນຂອງການທົດສອບ |
ເບື້ອງຫຼັງການເຮັດວຽກແມ່ນຫຍັງ?
ເພື່ອທົດສອບການບິວດ໌ ພວກເຮົາຈະ:
-
ດຶງຂໍ້ມູນ (checkout) ຈາກຄັງເກັບ dist-git
-
ເອົາອິເມຈ qcow ຫຼ້າສຸດຂອງ Fedora Rawhide
-
ຕິດຕັ້ງທຸກແພັກເກັດຈາກການບິວດ໌ຂອງ koji ລົງໃສ່ມັນ
-
ລັນ ansible playbook ທີ່ກຳນົດໄວ້ໃນ tests.yml
ຂ້ອຍຈະກວດສອບການກຳນົດຄ່າຂອງຂ້ອຍໄດ້ແນວໃດ?
ມັນເປັນໄປໄດ້ທີ່ຈະລັນ ແລະ ກວດແກ້ (debug) standard test roles ຢູ່ພາຍໃນເຄື່ອງ. ແຕ່ພວກເຮົາຂໍແນະນຳໃຫ້ໃຊ້ຂັ້ນຕອນການເຮັດວຽກແບບ pull-request: ພຽງແຕ່ສ້າງ pull-request ແລະ ລໍຖ້າໃຫ້ CI ຕອບສະໜອງຕໍ່ມັນ.
ພວກເຮົາເອີ້ນໃຊ້ກົນໄກ CI ເກືອບຈະຄືກັນກັບການທົດສອບ PR ຕາມທີ່ໃຊ້ສຳລັບ gating ຂອງການບິວດ໌ໃໝ່.
ແລະ ທັນທີທີ່ຜົນການທົດສອບພ້ອມແລ້ວ, ມັນຈະປາກົດຢູ່ໃນໜ້າ pull request ໃນ [Fedora Pagure]
ເພື່ອເລີ່ມການທົດສອບໃໝ່ ໃຫ້ເພີ່ມຄຳເຫັນໃສ່ PR ໃນ Pagure, ດ້ວຍເນື້ອໃນດັ່ງນີ້: [citest]
Want to help? Learn how to contribute to Fedora Docs ›