ໃນໂພສກ່ອນໜ້ານີ້ຂອງພວກເຮົາ, ພວກເຮົາໄດ້ເຫັນວິທີການກວດຫາ ແລະ ປ້ອງກັນຈາກສານພິດໂດຍກົງ Pipeline ການປະຕິບັດ (D-PPE). ພວກເຮົາຍັງໄດ້ເຫັນວິທີການກວດຫາຊ່ອງໂຫວ່ດັ່ງກ່າວໂດຍໃຊ້ ເຄື່ອງສະແກນ Xygeni, ເຊັ່ນດຽວກັນກັບກົນໄກການປົກປ້ອງບາງຢ່າງ.
ເປັນພິດ Pipeline ການປະຕິບັດ (PPE) ຖືກສ້າງຂຶ້ນເມື່ອຜູ້ໂຈມຕີສາມາດດັດແປງ pipeline ເຫດຜົນໃນສອງວິທີ:
- ໂດຍການດັດແປງໄຟລ໌ການຕັ້ງຄ່າ CI (ໄຟລ໌ pipeline) -> ອຸປະກອນປ້ອງກັນສ່ວນຕົວໂດຍກົງ (D-PPE)
- ໂດຍການດັດແປງໄຟລ໌ທີ່ອ້າງອີງໂດຍ pipeline (ຕົວຢ່າງ: ສະຄຣິບທີ່ອ້າງອີງຈາກພາຍໃນ pipeline ໄຟລ໌ການຕັ້ງຄ່າ) -> ອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນທາງອ້ອມ (I-PPE)
ໃນໂພສນີ້, ພວກເຮົາຈະເຂົ້າໄປເບິ່ງລາຍລະອຽດກ່ຽວກັບ Indirect PPE. ແຕ່ກ່ອນໜ້ານັ້ນ, ແລະເປັນການເສີມໃຫ້ກັບໂພສກ່ອນໜ້ານີ້ຂອງຂ້ອຍ, ໃຫ້ພວກເຮົາເບິ່ງກ່ອນວ່າ GitHub ຈັດການການປະຕິບັດແນວໃດ pipelines ແລະກົນໄກປ້ອງກັນຕ້ານ D-PPE ແມ່ນຫຍັງ.
GitHub ປົກປ້ອງການປະຕິບັດຂອງ pipelineມາຈາກ PRs ບໍ?
GitHub ເຮັດວຽກແນວໃດກ່ຽວກັບການປະຕິບັດການດັດແປງ pipelines?
ຖືກແກ້ໄຂ pipelines ສາມາດມາຈາກ Pushes ຫຼື Pull Requests (ປທ). ໃນຖານະເປັນວິທີປະຕິບັດທີ່ດີທີ່ສຸດ, ຂໍແນະນຳຢ່າງຍິ່ງໃຫ້ຫຼີກລ່ຽງການ "ຍູ້" ໂດຍກົງໄປຫາສາຂາທີ່ໄດ້ຮັບການປົກປ້ອງ ແລະ ການນຳໃຊ້ Pull Requests ເປັນກົນໄກໃນການບັງຄັບໃຊ້ການທົບທວນຄືນບາງຢ່າງກ່ອນທີ່ຈະຍອມຮັບລະຫັດໃດໆທີ່ປະກອບສ່ວນ.
Pull Requests ອາດຈະມາຈາກສອງແຫຼ່ງທີ່ແຕກຕ່າງກັນ:
- PR ມາຈາກ forks
- PR ມາຈາກ ສາຂາ
PR ຈາກ forks ສາມາດມາຈາກ ສາທາລະນະ or ສ່ວນຕົວ ຫໍສະ ໝຸດ.
ໃນຂະນະທີ່ພວກເຮົາກຳລັງຈັດການກັບອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນ (ອຸປະກອນປ້ອງກັນສານພິດ) Pipeline ການປະຕິບັດ), ຈຸດຫຼັກຂອງພວກເຮົາແມ່ນບໍ່ແມ່ນ "ການຍອມຮັບ" ຂອງ PR ແຕ່ແມ່ນການປະຕິບັດຂອງການແກ້ໄຂ pipeline ໃນລະຫວ່າງຂະບວນການຍອມຮັບ/ອະນຸມັດຂອງ PR. ໃນຫຼັກຂອງການໂຈມຕີ PPE, ມີການປະຕິບັດທີ່ບໍ່ໄດ້ຕັ້ງໃຈຂອງການດັດແປງ "ທີ່ມີເຈດຕະນາຮ້າຍ" pipeline.
ໃນສອງສາມຄຳ, ເປັນພິດ Pipeline ການປະຕິບັດ (PPE) ແມ່ນຜະລິດເມື່ອ ຜູ້ໂຈມຕີສາມາດດັດແປງໄດ້ pipeline ຕາມເຫດຜົນ.
ມີສອງ variants:
- ອຸປະກອນປ້ອງກັນສ່ວນຕົວໂດຍກົງ (ອຸປະກອນປ້ອງກັນສ່ວນຕົວ (D-PPE)ໃນສະຖານະການ D-PPE, ຜູ້ໂຈມຕີດັດແປງໄຟລ໌ config CI ໃນບ່ອນເກັບຂໍ້ມູນທີ່ພວກເຂົາສາມາດເຂົ້າເຖິງໄດ້, ໂດຍການຍູ້ການປ່ຽນແປງໂດຍກົງໄປຫາສາຂາໄລຍະໄກທີ່ບໍ່ໄດ້ຮັບການປົກປ້ອງໃນ repo, ຫຼືໂດຍການສົ່ງ PR ດ້ວຍການປ່ຽນແປງຈາກສາຂາ ຫຼື ສ້ອມ. ນັບຕັ້ງແຕ່ CI pipeline ການປະຕິບັດຖືກກຳນົດໂດຍຄຳສັ່ງໃນໄຟລ໌ການຕັ້ງຄ່າ CI ທີ່ຖືກດັດແປງ, ຄຳສັ່ງທີ່ເປັນອັນຕະລາຍຂອງຜູ້ໂຈມຕີໃນທີ່ສຸດຈະເຮັດວຽກຢູ່ໃນໂຫນດ build ເມື່ອ build pipeline ຖືກກະຕຸ້ນ.
- ອຸປະກອນປ້ອງກັນສ່ວນຕົວທາງອ້ອມ (ອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນ (I-PPE)ໃນບາງກໍລະນີ, ຄວາມເປັນໄປໄດ້ຂອງ D-PPE ແມ່ນບໍ່ມີໃຫ້ສຳລັບສັດຕູທີ່ສາມາດເຂົ້າເຖິງໄດ້ SCM ບ່ອນເກັບມ້ຽນຂໍ້ມູນ (ຕົວຢ່າງເຊັ່ນ ຖ້າ pipeline ຖືກຕັ້ງຄ່າໃຫ້ດຶງໄຟລ໌ການຕັ້ງຄ່າ CI ຈາກສາຂາແຍກຕ່າງຫາກທີ່ໄດ້ຮັບການປົກປ້ອງໃນບ່ອນເກັບຂໍ້ມູນດຽວກັນ). ໃນສະຖານະການດັ່ງກ່າວ, ແທນທີ່ຈະເຮັດໃຫ້ເປັນພິດ pipeline ຕົວມັນເອງ, ຜູ້ໂຈມຕີຈະສັກລະຫັດທີ່ເປັນອັນຕະລາຍເຂົ້າໄປໃນໄຟລ໌ທີ່ອ້າງອີງໂດຍ pipeline (ຕົວຢ່າງ: ສະຄຣິບທີ່ອ້າງອີງຈາກພາຍໃນ pipeline ໄຟລ໌ການຕັ້ງຄ່າ)
ໃນທັງສອງກໍລະນີ, GitHub ຈະປະຕິບັດການແກ້ໄຂ pipeline ໂດຍບໍ່ຈຳເປັນຕ້ອງມີການທົບທວນຄືນ ຫຼື ການອະນຸມັດກ່ອນໜ້ານີ້.
PR ຈາກ forks ຕໍ່ ສາທາລະນະ ສ່ວນທີ່ເຫຼືອ
GitHub ອະນຸຍາດໃຫ້ຕັ້ງຄ່າພຶດຕິກຳໃນເວລາປະມວນຜົນ PRs ມາຈາກ forks ໃນ repos ສາທາລະນະ.
ເມື່ອ PR ມາຈາກ fork, GitHub ສະເຫມີບັງຄັບໃຫ້ມີລະດັບ "ການອະນຸມັດ" ກ່ອນທີ່ຈະປະຕິບັດ pipeline ທີ່ກ່ຽວຂ້ອງກັບ PRລະດັບການອະນຸມັດນີ້ປ່ຽນຈາກການອະນຸມັດທີ່ອ່ອນແອໄປສູ່ການອະນຸມັດທີ່ເຂັ້ມງວດ.
At ລະດັບອົງກອນ (ອົງກອນ>>ການຕັ້ງຄ່າ>>ການກະທຳ>>ທົ່ວໄປ), ທ່ານສາມາດຕັດສິນໃຈເລືອກຕົວເລືອກ "ການອະນຸມັດ" ຫຼາຍຢ່າງ:
ທີ່ເຂັ້ມງວດທີ່ສຸດແມ່ນອັນສຸດທ້າຍ (“ຕ້ອງການການອະນຸມັດຈາກຜູ້ຮ່ວມມືພາຍນອກທັງໝົດ”) ເພາະວ່າ GitHub ຈະຕ້ອງການການອະນຸມັດສະເໝີເມື່ອ PR ມາຈາກ forks ຈາກຜູ້ຮ່ວມມືພາຍນອກ.
ແຕ່ເຖິງແມ່ນວ່າໃນກໍລະນີທີ່ເຄັ່ງຄັດນີ້, ກໍ່ຍັງມີ ຄວາມແຕກຕ່າງລະຫວ່າງຜູ້ຮ່ວມມືທີ່ມີສິດອະນຸຍາດໃນການອ່ານ ແລະ ຂຽນ.
- ເມື່ອ PR ມາຈາກ ອ່ານ ຜູ້ໃຊ້, ທີ່ ການປະຕິບັດຂອງ pipeline ຖືກຢຸດ ຈົນກວ່າຈະມີການອະນຸມັດການປ່ຽນແປງ. ຖ້າການອະນຸມັດດີ, ຫຼັງຈາກນັ້ນການແກ້ໄຂ pipeline ຖືກປະຫານຊີວິດ.
- ເມື່ອ PR ມາຈາກ ຂຽນ ຜູ້ໃຊ້, ທີ່ ບໍ່ຈຳເປັນຕ້ອງມີການອະນຸມັດ ແລະ ການດັດແປງ pipeline ຖືກປະຕິບັດສະເໝີ !!
ສະຫຼຸບແລ້ວ, PRs ທີ່ມາຈາກ forks ໃນບ່ອນເກັບມ້ຽນສາທາລະນະແມ່ນໄດ້ຮັບການປົກປ້ອງເບົາບາງຈາກ PPE. ມີການປ້ອງກັນບາງຢ່າງຕໍ່ຜູ້ໃຊ້ພາຍນອກ (ອ່ານ), ແຕ່ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບຜູ້ໃຊ້ພາຍໃນ (ຂຽນ).
ສິ່ງທີ່ກ່ຽວກັບ PRs ມາຈາກ forks ຈາກ repos ສ່ວນຕົວ?
PR ຈາກ forks ຕໍ່ ສ່ວນຕົວ ສ່ວນທີ່ເຫຼືອ
ໃນສະຖານະການນີ້, GitHub ໃຫ້ການຕັ້ງຄ່າທີ່ເປັນປະໂຫຍດບາງຢ່າງ.
ການຕັ້ງຄ່າຂ້າງເທິງນີ້ສາມາດຕັ້ງຄ່າໄດ້ທີ່ ອະໄວຍະວະ ຫຼືຢູ່ repo ລະດັບ.
ເມື່ອໃດ ບໍ່ມີຕົວເລືອກໃດຖືກເລືອກ, GitHub ຈະ ຂໍການອະນຸມັດ ແລະ ມັນຈະບໍ່ປະຕິບັດການແກ້ໄຂ pipelineນີ້ແມ່ນການຕັ້ງຄ່າທີ່ປອດໄພທີ່ສຸດ!!
ໄດ້ ການຕັ້ງຄ່າທີ່ບໍ່ປອດໄພທີ່ສຸດ ແມ່ນເວລາໃດ "ດໍາເນີນການເຮັດວຽກຈາກ fork pull request"ຖືກກວດສອບແລ້ວໃນກໍລະນີນີ້, ຄືກັນກັບຜູ້ໃຊ້ທີ່ອ່ານ ແລະ ຂຽນ, Github ຈະປະຕິບັດການແກ້ໄຂໂດຍອັດຕະໂນມັດ pipeline!! ແລະສະຖານະການນີ້ສາມາດເປັນໄດ້ເຖິງແມ່ນວ່າ ຮ້າຍແຮງກວ່າເກົ່າ ຖ້າ "ສົ່ງໂທເຄັນການຂຽນໄປຫາຂັ້ນຕອນການເຮັດວຽກຈາກ fork pull requests"ແລະ"ສົ່ງຄວາມລັບ ແລະ ຕົວແປໄປຫາ workflows ຈາກ fork pull requests” ຖືກກວດສອບແລ້ວ. ຢ່າເຮັດສິ່ງນີ້ເວັ້ນເສຍແຕ່ວ່າມັນມີເຫດຜົນທີ່ຊັດເຈນ!!
ຖ້າ“ຕ້ອງການການອະນຸມັດສຳລັບສ້ອມ pull request workflows” ຖືກກວດສອບແລ້ວ, ສະຖານະການຂ້າງເທິງນີ້ໄດ້ຮັບການປັບປຸງໃຫ້ດີຂຶ້ນບາງຢ່າງ: GitHub ຈະຂໍການອະນຸມັດ ແລະ ບໍ່ປະຕິບັດການແກ້ໄຂ pipeline ສຳລັບຜູ້ໃຊ້ທີ່ອ່ານ, ແຕ່ມັນຍັງຈະປະຕິບັດມັນສຳລັບຜູ້ໃຊ້ທີ່ຂຽນ.
ເຫັນສ້ອມແລ້ວ, ຈະເປັນແນວໃດກ່ຽວກັບມັນ PRs ມາຈາກສາຂາຕ່າງໆ?
PR ຈາກ ສາຂາ
ເພື່ອປົກປ້ອງສະຖານະການນີ້ ທ່ານຕ້ອງອີງໃສ່ ກົດລະບຽບການປົກປ້ອງສາຂາ.
ໃນລະດັບ repo, ທ່ານສາມາດສ້າງກົດລະບຽບການປົກປ້ອງສາຂາສຳລັບສາຂາໃດກໍໄດ້. ກົດລະບຽບເຫຼົ່ານີ້ເພີ່ມບາງຢ່າງ ຂໍ້ຈຳກັດຕໍ່ການດັດແປງສາຂາທີ່ໄດ້ຮັບການປົກປ້ອງ.
ເຖິງແມ່ນວ່າທ່ານຈະຕັ້ງຄ່າກົດລະບຽບໃຫ້ "ຕ້ອງການ ກ pull request ກ່ອນການລວມຕົວ"ແລະ"ຕ້ອງການການອະນຸມັດ" ທີ່ຖືກດັດແກ້ pipeline ຈະຖືກປະຕິບັດໂດຍອັດຕະໂນມັດເມື່ອສ້າງ PR"ການອະນຸມັດ" ຈະໃຊ້ໄດ້ກັບການດຳເນີນການລວມເທົ່ານັ້ນ.
ຈະເປັນແນວໃດກ່ຽວກັບການເປັນພິດທາງອ້ອມ Pipeline ການບໍລິຫານ
ດັ່ງທີ່ພວກເຮົາໄດ້ເຫັນຂ້າງເທິງ, D-PPE ສາມາດຫຼຸດຜ່ອນໄດ້ໂດຍການໃຊ້ ດຶງ_ຄຳຮ້ອງຂໍ_ເປົ້າໝາຍ, ແຕ່ມັນ ບໍ່ໄດ້ໃຊ້ກັບ I-PPE.
ຖ້າທ່ານໃຊ້ pull_request_target, ການກວດສອບຄ່າເລີ່ມຕົ້ນຈະເປັນລະຫັດພື້ນຖານ. ແຕ່ຖ້າທ່ານຕ້ອງການກວດສອບບາງຢ່າງກ່ຽວກັບລະຫັດທີ່ປະກອບສ່ວນ (ລະຫັດ PR), ທ່ານຈໍາເປັນຕ້ອງກວດສອບລະຫັດ PR ຢ່າງຊັດເຈນ. ດັ່ງນັ້ນ, ຖ້າລະຫັດ PR ໄດ້ດັດແປງ shell script ໃດໆທີ່ຖືກເອີ້ນໂດຍ pipeline, “ພື້ນຖານ” (ປອດໄພ) pipeline ຈະເອີ້ນໃຊ້ສະຄຣິບເຊວ “ດັດແປງ” → PPE ທາງອ້ອມ!!
ວິທີແກ້ໄຂບັນຫານີ້ແມ່ນສັບສົນກວ່າໜ້ອຍໜຶ່ງ (ບໍ່ມີວິທີໃດທີ່ງ່າຍຄືກັບ pull_request_target).
ຂອງພວກເຮົາ pipeline ດຽວນີ້ປອດໄພຕໍ່ກັບ D-PPE ເພາະວ່າພວກເຮົາກຳລັງໃຊ້ pull_request_target. ແຕ່ມັນຍັງມີຄວາມສ່ຽງຕໍ່ການຕິດເຊື້ອ I-PPE.
ໃນຕົວຢ່າງການທົດສອບຂອງພວກເຮົາ, ພວກເຮົາຈຳເປັນຕ້ອງກວດສອບລະຫັດ PR ໂດຍພື້ນຖານແລ້ວເພື່ອສ້າງ build, ແຕ່ການທົດສອບແມ່ນປະຕິບັດກ່ຽວກັບສິ່ງປະດິດທີ່ສ້າງຂຶ້ນໂດຍ build.
ດັ່ງນັ້ນ .. ເປັນຫຍັງຈຶ່ງບໍ່ກວດສອບທັງສອງ codebase?
- ກວດສອບລະຫັດ PR ເພາະວ່າລະຫັດທີ່ປະກອບສ່ວນແມ່ນສິ່ງທີ່ພວກເຮົາຕ້ອງການສ້າງ ແລະ ທົດສອບ
- ລະຫັດ Checkout Base ເພື່ອໃຊ້ລຸ້ນຕົ້ນສະບັບຂອງ pipeline ແລະ ສະຄຣິບ build/tests
ສິ່ງນີ້ອາດຈະເຮັດໄດ້ໂດຍ ກວດສອບຖານຂໍ້ມູນເຫຼົ່ານັ້ນໄປຍັງໂຟນເດີຕ່າງໆລະຫັດພື້ນຖານອາດຈະຖືກກວດສອບໄປຍັງໂຟນເດີຮາກ, ແລະ PR ໄປຍັງໂຟນເດີອື່ນ. ໃນກໍລະນີນີ້, ພວກເຮົາຈະປະຕິບັດການສ້າງ ແລະ ສະຄຣິບທົດສອບຈາກໂຟນເດີຮາກທຽບກັບລະຫັດທີ່ວາງໄວ້ໃນໂຟນເດີໃໝ່.
ແນ່ນອນ, ນີ້ແມ່ນວິທີແກ້ໄຂທີ່ງ່າຍ!! ແຕ່, ເພື່ອຈຸດປະສົງການຮຽນຮູ້, ຂ້ອຍຢາກແນະນຳຕົວແປທີ່ໜ້າສົນໃຈຫຼາຍ (...)
GitHub ການເຮັດວຽກແບບເຮັດວຽກ ເຫດການກະຕຸ້ນ
ນອກຈາກ ດຶງ_ຄຳຮ້ອງຂໍ_ເປົ້າໝາຍ, GitHub ໃຫ້ເຫດການກະຕຸ້ນອີກອັນໜຶ່ງ: ການເຮັດວຽກແບບເຮັດວຽກກິດຈະກຳນີ້ອະນຸຍາດໃຫ້ ການປະຕິບັດຂອງ a pipeline ຖືກປັບໃຫ້ເຂົ້າກັບຄົນອື່ນ pipelineການປະຕິບັດຂອງ.
ການເຮັດວຽກແບບເຮັດວຽກ ແລະ ດຶງ_ຄຳຮ້ອງຂໍ_ເປົ້າໝາຍ ຕົວກະຕຸ້ນແມ່ນຄ້າຍຄືກັນໃນລັກສະນະໜຶ່ງ: ທັງສອງຈະຖືກປະຕິບັດໃນໂໝດສິດທິພິເສດ ແລະ ເຖິງວ່າຈະມີການດັດແປງ PR ກໍຕາມ, ພື້ນຖານ pipeline ຈະຖືກປະຫານຊີວິດ!!
ລອງມາເບິ່ງປະຈຸບັນຂອງພວກເຮົາ pipeline:
ພາກສ່ວນກໍ່ສ້າງແມ່ນປອດໄພຕໍ່ກັບ D-PPE, ແຕ່ພາກສ່ວນທົດສອບຍັງມີຄວາມສ່ຽງຕໍ່ກັບ I-PPE.
ໄດ້ pipeline ຕົວມັນເອງປອດໄພຕໍ່ກັບ D-PPE ເນື່ອງຈາກ ດຶງ_ຄຳຮ້ອງຂໍ_ເປົ້າໝາຍ ຕົວກະຕຸ້ນ. ແຕ່ຂັ້ນຕອນການທົດສອບຍັງມີຄວາມສ່ຽງຕໍ່ການ I-PPE ເນື່ອງຈາກການເອີ້ນໃຊ້ສະຄຣິບເຊວພາຍນອກ.
ການຫຼີກລ່ຽງອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນ (I-PPE)
ຈຸດປະສົງຂອງຂ້າງເທິງ pipeline ແມ່ນເພື່ອສ້າງ ແລະ ທົດສອບລະຫັດທີ່ປະກອບສ່ວນ, ໂດຍປອດໄພຕໍ່ອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນ (PPE).
ດັ່ງນັ້ນ .. ເປັນຫຍັງບໍ່ແບ່ງກັນ pipeline ເປັນສອງ? ອັນໜຶ່ງສຳລັບການກໍ່ສ້າງ ແລະ ອີກອັນໜຶ່ງສຳລັບການທົດສອບ..
- ທີ 1 pipeline (ສ້າງ CI) ຈະ ກວດສອບລະຫັດ PR (ເພື່ອສ້າງມັນ), ສ້າງສິ່ງກໍ່ສ້າງ ແລະ ສ້າງສິ່ງປະດິດ.
- ທີ 2 pipeline (ການທົດສອບ CI) ຈະ ກວດສອບລະຫັດພື້ນຖານ (ເພື່ອຫຼີກເວັ້ນການດັດແປງສະຄຣິບ shell) ແລະປະຕິບັດສະຄຣິບຕົ້ນສະບັບຕໍ່ກັບສິ່ງປະດິດ.
- ເພື່ອປະສານ CI ການທົດສອບ pipeline ເພື່ອດໍາເນີນການຫຼັງຈາກ Build CI pipeline, ພວກເຮົາຈະໃຊ້ ການເຮັດວຽກແບບເຮັດວຽກ ຜົນກະທົບຕໍ່.
ໃນວິທີນີ້:
- pipeline ສ້າງ CI is ປອດໄພ ທັງສອງ ອຸປະກອນປ້ອງກັນສ່ວນຕົວ (D-PPE) (ເນື່ອງຈາກ ດຶງ_ຄຳຮ້ອງຂໍ_ເປົ້າໝາຍ) ແລະ ອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນ (I-PPE) (ເພາະມັນບໍ່ໄດ້ປະຕິບັດ shell script ອີກຕໍ່ໄປ).
- pipeline ການທົດສອບ CI ແມ່ນຍັງ ປອດໄພ ທັງສອງ ອຸປະກອນປ້ອງກັນສ່ວນຕົວ (D-PPE) (ເນື່ອງຈາກ ການເຮັດວຽກແບບເຮັດວຽກ) ແລະ ອຸປະກອນປ້ອງກັນສ່ວນບຸກຄົນ (I-PPE) (ເພາະມັນກວດສອບລະຫັດພື້ນຖານເພື່ອໃຫ້ໄດ້ສະຄຣິບ shell ຕົ້ນສະບັບ)
ລອງເບິ່ງລະຫັດຂອງທັງສອງ pipelines ອີງຕາມການດັດແປງເຫຼົ່ານີ້ ...
1st pipeline (ສ້າງ CI):
2nd pipeline (ການທົດສອບ CI):
ວ້າວ... ວິທີແກ້ໄຂທີ່ດີ!! ແຕ່ ….. ພວກເຮົາປອດໄພບໍ? ຂ້ອຍຢ້ານວ່າບໍ່ 😭
ແມ່ນແລ້ວ, ພວກເຮົາໄດ້ນຳສະເໜີຊ່ອງໂຫວ່ໃໝ່!! ຊ່ອງໂຫວ່ໃດ? ນີ້ຈະເປັນຫົວຂໍ້ຂອງໂພສຕໍ່ໄປຂອງພວກເຮົາ 🙂 … ຕິດຕາມຕໍ່ໄປ!!
PS: ຂໍໂທດ, ຂ້ອຍບໍ່ສາມາດຢູ່ງຽບໆໄດ້🤐 .. ເຈົ້າເຄີຍໄດ້ຍິນກ່ຽວກັບ ການເປັນພິດຈາກສິ່ງປະດິດ ? 😂
