ວິທີເພີ່ມການທົດສອບ STI ແບບງ່າຍໆ ສຳລັບແພັກເກັດ

ທົດສອບເປັນຄຳສັ່ງດຽວ

ວຽກງານ

ມີແພັກເກັດ somepackage, ເຊິ່ງບັນຈຸໄຟລ໌ໄບນາຣີ (binary): /usr/bin/somebinary

ວິທີທີ່ງ່າຍ ແລະ ຊັດເຈນທີ່ສຸດໃນການທົດສອບໄບນາຣີນີ້ແມ່ນການລັນ (run) ມັນ: somebinary --help ແລະ ກວດສອບສະຖານະການອອກ (exit status) ຂອງຜົນລັບ.

ຈະເພີ່ມການທົດສອບນີ້ໃຫ້ກັບແພັກເກັດໄດ້ແນວໃດ?

ໂຄງຮ່າງ (framework) [Standard Test Roles] ໃຫ້ທາງອອກສຳລັບວຽກງານນີ້. ມັນໄດ້ຮັບການຮອງຮັບຢ່າງເຕັມຮູບແບບໃນ Fedora Rawhide.

ວິທີແກ້ໄຂ

ສ້າງໄຟລ໌ tests/tests.yml ໃນ dist-git ຂອງແພັກເກັດ:

rpms/somepackage.git:
.
├── 0001-something.patch
├── somepackage.spec
├── sources
└── tests
    └── tests.yml

tests.yml ແມ່ນ ansible playbook, ບ່ອນທີ່ທ່ານກຳນົດສະພາບແວດລ້ອມການທົດສອບ ແລະ ຂັ້ນຕອນໃນການລັນການທົດສອບຂອງທ່ານ.

ມີຫຼາຍຕົວເລືອກ ແລະ [ຕົວຢ່າງທີ່ມີໃຫ້], ແຕ່ໃຫ້ເຮົາມາເນັ້ນໃສ່ວຽກງານທີ່ກຳລັງເຮັດຢູ່: ພວກເຮົາຕ້ອງການລັນພຽງແຕ່ຄຳສັ່ງດຽວ.

ສຳລັບກໍລະນີນີ້ ເນື້ອໃນຂອງໄຟລ໌ຄວນເປັນດັ່ງນີ້:

rpms/somepackage.git:tests/tests.yml
- 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 ທີ່ມີເນື້ອໃນດັ່ງນີ້:

rpms/somepackage.git:tests/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 ຄຳສັ່ງປະຕິບັດການທົດສອບ

ການທົດສອບໃນ source tarball

ການທົດສອບໃນຄັງເກັບພາຍນອກ (external repository)

ວຽກງານ

ບາດນີ້ ມາເບິ່ງການຕັ້ງຄ່າທີ່ຊັບຊ້ອນຂຶ້ນເລັກນ້ອຍ.

ສົມມຸດວ່າມີແພັກເກັດ somepackage ທີ່ພວກເຮົາກຳລັງຈະທົດສອບ. ມີຊຸດການທົດສອບແບບບູລະນາການສຳລັບມັນ, ເຊິ່ງ (ໜ້າເສຍດາຍ) ຍັງບໍ່ທັນໄດ້ຖືກເຮັດເປັນແພັກເກັດ ແລະ ຕັ້ງຢູ່ໃນຄັງເກັບ git ແຍກຕ່າງຫາກ https://somewhere/sometests.git. ຊຸດການທົດສອບມີການຂຶ້ນຕໍ່ກັບ (dependency) ເຄື່ອງມື sometool ບາງຢ່າງທີ່ຖືກເຮັດເປັນແພັກເກັດແລ້ວ. ແລະ ໃນຄັງເກັບການທົດສອບມີສະຄຣິບ run_some_tests ເຊິ່ງຈະເອີ້ນໃຊ້ການທົດສອບ.

ເປົ້າໝາຍແມ່ນເພື່ອເອີ້ນໃຊ້ການປະຕິບັດຊຸດການທົດສອບສຳລັບແພັກເກັດ.

ວິທີແກ້ໄຂ

ພວກເຮົາຈຳເປັນຕ້ອງສ້າງໄຟລ໌ກຳນົດຄ່າ tests.yml ທີ່ມີເນື້ອໃນດັ່ງນີ້:

rpms/somepackage.git: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.

rpms/somepackage.git:
.
├── 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]