หน้าแรก>การเขียนโปรแกรมที่เกี่ยวข้อง>ซอร์สโค้ดอื่น ๆ
ดาวน์โหลด

Garuda Linux PKGBUILD

พื้นที่เก็บข้อมูลนี้มี PKGBUILD สำหรับแพ็คเกจทั้งหมดที่อยู่ในพื้นที่เก็บข้อมูล garuda ในปัจจุบัน ดำเนินการบน GitLab เนื่องจากมีการใช้ CI อย่างกว้างขวางและมีมิเรอร์ GitHub แบบอ่านอย่างเดียว

ขอบเขตของการซื้อคืนนี้

PKGBUILD ของเราทั้งหมดมีอยู่ที่นี่ ในอดีต สิ่งเหล่านี้ถูกแบ่งออกเป็นพื้นที่เก็บข้อมูลของตัวเอง เพื่อให้การค้นหา PKGBUILD ที่ถูกต้องง่ายขึ้น และช่วยให้มีส่วนร่วมได้เร็วขึ้น เราจึงได้รวมพวกมันไว้ในที่เก็บใหม่นี้ รวมอยู่ด้วยคือ PKGBUILD ของแพ็คเกจทั้งหมดรวมถึงไฟล์กำหนดค่า (ซึ่งใช้กับไฟล์ขนาดเล็กเช่น garuda-fish-config ) สำหรับบางส่วน เช่น แพ็คเกจ garuda-*-settings เนื้อหาอาจยังพบอยู่ในที่เก็บข้อมูลที่เกี่ยวข้อง

พบปัญหาใดๆ?

หากเกิดปัญหาเกี่ยวกับบรรจุภัณฑ์หรือสิ่งที่คล้ายกัน อย่าลังเลที่จะรายงานผ่านส่วนปัญหาของเรา คุณสามารถคลิกที่นี่เพื่อสร้างใหม่

จะมีส่วนร่วมได้อย่างไร?

เราขอขอบคุณอย่างยิ่งสำหรับการมีส่วนร่วมทุกประเภท! - โดยทำตามขั้นตอนเหล่านี้:

  • สร้างทางแยกของที่เก็บนี้
  • โคลนส้อมของคุณในเครื่อง (บทช่วยสอนสั้น ๆ ของ git)
  • เพิ่มการเปลี่ยนแปลงที่ต้องการให้กับ PKGBUILD หรือซอร์สโค้ด
  • ตรวจสอบให้แน่ใจว่าเชลล์ตรวจสอบและรายงาน shfmt ไม่มีปัญหากับไฟล์ที่เปลี่ยนแปลง
    • จำเป็นต้องติดตั้งการพึ่งพาที่จำเป็นก่อน เช่น ผ่าน sudo pacman -S shfmt shellcheck
    • รันสคริปต์ lint.sh ผ่าน bash ./.ci/lint.sh ตรวจสอบโค้ด
    • ใช้คำแนะนำบางอย่างโดยอัตโนมัติผ่าน bash ./ci/lint.sh apply
  • คอมมิตโดยใช้ข้อความคอมมิตแบบเดิมๆ และผลักการเปลี่ยนแปลงใดๆ กลับไปที่ทางแยกของคุณ
    • แอปพลิเคชัน Commizen ช่วยในการสร้างข้อความยืนยันที่เหมาะสม คุณสามารถติดตั้งผ่าน pip ได้เนื่องจากขณะนี้ไม่มีแพ็คเกจใน Arch repos: pip install --user -U Commitizen จากนั้นดำเนินการต่อด้วยการรัน cz commit ในโฟลเดอร์ที่โคลน
  • สร้างคำขอรวมใหม่ที่พื้นที่เก็บข้อมูลหลักของเรา
  • ตรวจสอบว่าการรันไปป์ไลน์ใดๆ ล้มเหลวหรือไม่ และใช้คำแนะนำในที่สุด

จากนั้นเราจะตรวจสอบการเปลี่ยนแปลงและรวมเข้าด้วยกันในที่สุด

การจัดการปัญหาบรรจุภัณฑ์บางอย่าง

แพ็คเกจที่เลิกใช้แล้วและใช้งานไม่ได้

มีบางกรณีของแพ็คเกจที่เลิกใช้แล้ว ซึ่งไม่มีจุดประสงค์อีกต่อไป และยังทำให้ระบบไม่สามารถอัปเดตได้ สิ่งเหล่านี้สามารถจัดการได้โดยการเพิ่มแพ็คเกจไปที่ conflicts() ของ garuda-common-settings และ auto-pacman ของ garuda-update ผลลัพธ์ก็คือแพ็คเกจที่ละเมิดจะถูกลบออกโดยอัตโนมัติเนื่องจากข้อขัดแย้ง

CI / เครื่องมือสร้าง

ข้อมูลต่อไปนี้นำมาจากเอกสารประกอบเครื่องมือ build บางส่วน โดยละเว้นข้อมูลที่ไม่เกี่ยวข้องกับ repo นี้ ในกรณีที่คุณกำลังมองหาคำแนะนำในการตั้งค่า โปรดอ่าน README แบบเต็มแทน

ทั่วไป

การปรับใช้อาจถูกทริกเกอร์โดยอัตโนมัติโดยการเปลี่ยนแปลงเนื้อหาภายในไดเร็กทอรี PKGBUILD หรือต่อท้าย [deploy *] เข้ากับข้อความคอมมิต ต่างจากการตรวจสอบ PKGBUILD ตรงที่มีให้สำหรับคอมมิตในสาขา main เท่านั้น รองรับคือ:

  • [deploy all] : ปรับใช้รูทีน garuda แบบเต็ม ซึ่งหมายถึง PKGBUILD ทั้งหมดในที่เก็บนี้
  • [deploy $pkgname] : ปรับใช้แพ็คเกจ pkgname ซึ่งหมายความว่าโดยการแทนที่สิ่งนี้ด้วย garuda-bash-settings เราจะปรับใช้ garuda-bash-settings

เมื่อตรวจพบชุดค่าผสมเหล่านี้ การปรับใช้จะเริ่มต้นหลังจากการตรวจสอบไม่กี่ครั้งเสร็จสมบูรณ์ บันทึกของการปรับใช้ที่ผ่านมาสามารถตรวจสอบได้ผ่านส่วนไปป์ไลน์

กระแทกอัตโนมัติ

พื้นที่เก็บข้อมูลนี้จัดเตรียมไปป์ไลน์ครึ่งชั่วโมงที่จะอัปเดต PKGBUILD ทั้งหมดเป็นเวอร์ชันล่าสุด หาก แหล่งที่มาอยู่ในพื้นที่เก็บข้อมูลอื่น โดยอิงตามแท็กล่าสุดที่มีอยู่ จากนั้นจะดำเนินการอัปเดตเช็คซัมและผลักดันการเปลี่ยนแปลงกลับไปยังสาขาหลัก การปรับใช้ใหม่จะถูกทริกเกอร์โดยอัตโนมัติโดยการต่อท้าย [deploy *] เข้ากับข้อความคอมมิต นั่นหมายความว่าการพุชแท็กใหม่เพื่อทริกเกอร์การใช้งานแพ็คเกจเวอร์ชันใหม่สำหรับแพ็คเกจเหล่านี้ก็เพียงพอแล้ว ประกาศสำคัญ:

  • สิ่งนี้ใช้ไม่ได้กับแพ็คเกจที่มีไฟล์ทั้งหมดอยู่ในที่เก็บนี้
  • แท็กต้องไม่ขึ้นต้นด้วย v
  • ข้อมูลที่จำเป็นเกี่ยวกับแหล่งที่มาของแพ็คเกจมีให้ผ่านไฟล์ SOURCES แต่ละบรรทัดเป็นไปตามรูปแบบ $url $pkgname $project_id ส่วนหลังใช้เพื่อดึงแท็กล่าสุดผ่าน GitLab API และสามารถพบได้ที่หน้าการตั้งค่าทั่วไปของพื้นที่เก็บข้อมูล

การรันล่าสุดของงานนี้สามารถตรวจสอบได้โดยการเรียกดูส่วนไปป์ไลน์ ทุกไปป์ไลน์ที่มีป้ายกำกับ ตามกำหนด เวลาจะถูกดำเนินการโดยตัวจับเวลา นอกจากนี้ ไปป์ไลน์สามารถทริกเกอร์ได้ด้วยตนเองโดยการเรียกดูส่วนกำหนดการไปป์ไลน์ และกดเรียก ใช้กำหนดการไปป์ไลน์

การอัปเดตเวอร์ชันด้วยตนเอง

สำหรับ PKGBUILD บางตัว เช่น garuda-fish-config ไฟล์ทั้งหมดจะอยู่ในที่เก็บนี้ เมื่ออัปเดต PKGBUILD โปรดตรวจสอบให้แน่ใจว่าได้อัปเดตไฟล์ .SRCINFO ที่เกี่ยวข้องด้วย เนื่องจากไฟล์นี้ใช้เพื่อแยกวิเคราะห์ข้อมูลที่เกี่ยวข้องกับแพ็คเกจทั้งหมด!

กำลังเพิ่มแพ็คเกจ

การเพิ่มแพ็คเกจนั้นง่ายพอ ๆ กับการสร้างโฟลเดอร์ใหม่ที่ตั้งชื่อตาม $pkgbase ของแพ็คเกจ ใส่ PKGBUILD และไฟล์ที่จำเป็นอื่นๆ ทั้งหมดไว้ที่นี่ การเพิ่มแพ็คเกจ AUR จึงง่ายพอๆ กับการโคลน repo และการลบโฟลเดอร์ . .git CI อาศัยไฟล์ .SRCINFO เพื่อแยกวิเคราะห์ข้อมูลส่วนใหญ่ ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องมีข้อมูลเหล่านั้นในสถานที่และเป็นปัจจุบันในกรณีของแพ็คเกจที่จัดการด้วยตนเอง สุดท้าย ให้เพิ่มโฟลเดอร์ .CI ที่มีการกำหนดค่าพื้นฐาน (จำเป็นต้องมี CI_PKGBUILD_SOURCE ในกรณีที่เป็นแพ็คเกจภายนอก PKBUILD ที่จัดการด้วยตนเองไม่จำเป็นต้องใช้) ยอมรับการเปลี่ยนแปลงใดๆ และผลักดันการเปลี่ยนแปลงกลับไปยังสาขาหลัก โปรดปฏิบัติตามข้อตกลงการคอมมิตแบบเดิมๆ ในขณะที่ทำเช่นนั้น (cz-cli สามารถช่วยได้!) ซึ่งหมายความว่ากระทำเช่น:

  • feat($pkgname): init
  • fix($pkgname): fix xyz
  • chore($pkgname): update PKGBUILD
  • ci(config): update

สิ่งนี้ไม่เพียงแต่ช่วยให้มีประวัติการคอมมิตที่สม่ำเสมอเท่านั้น แต่ยังช่วยสร้างบันทึกการเปลี่ยนแปลงอัตโนมัติอีกด้วย

การถอดแพ็คเกจ

ซึ่งสามารถทำได้โดยการลบโฟลเดอร์ที่มี PKGBUILD ของแพ็คเกจ งานล้างข้อมูลจะลบแพ็คเกจที่ล้าสมัยออกโดยอัตโนมัติผ่านการเรียกใช้ไปป์ไลน์ on-commit นี่จะพิจารณาแพ็คเกจแยกใดๆ ที่แพ็คเกจอาจผลิตด้วย การเปลี่ยนชื่อโฟลเดอร์จะนับเป็นการลบแพ็คเกจด้วย

ไปป์ไลน์ตามข้อผูกพัน

เมื่อใดก็ตามที่ผลักดันการคอมมิตใหม่ ไปป์ไลน์ CI จะดำเนินการดังต่อไปนี้:

  • ตรวจสอบว่าแท็ก scheduled ล่าสุดถูกสร้างขึ้นเมื่อใด ใช้เพื่อกำหนดแพ็คเกจที่ต้องกำหนดเวลา
  • แยกวิเคราะห์แต่ละคอมมิตสำหรับสตริง [deploy $foldername] โดยยอมรับเฉพาะค่าที่ถูกต้องที่ได้รับมาจากโฟลเดอร์ PKGBUILD ที่มีอยู่ [deploy all] ก็เป็นพารามิเตอร์ที่ถูกต้องเช่นกัน การสะกด $pkgname ผิดถือเป็นข้อผิดพลาดร้ายแรงที่นี่ ปัญหาใด ๆ จะต้องได้รับการแก้ไขและผลักดัน
  • จากนั้น ไฟล์ที่เปลี่ยนแปลงจะถูกแยกวิเคราะห์ รวมถึงแพ็คเกจที่ถูกลบออกด้วย เนื้อหาโฟลเดอร์ที่เกี่ยวข้องที่เปลี่ยนแปลงจะทำให้เกิดการปรับใช้แพ็คเกจของแพ็คเกจที่เกี่ยวข้อง
  • การดำเนินการขั้นสุดท้ายคือการสร้างพารามิเตอร์กำหนดการ (ส่งต่อให้กับงานที่กำหนดเวลาไว้ผ่านส่วนต่างๆ) และลบแพ็คเกจที่ล้าสมัยทั้งหมดออก ในกรณีที่ตรวจพบขั้นตอนก่อนหน้านี้
  • ในกรณีที่การดำเนินการทั้งหมดนี้สำเร็จ แท็ก scheduled จะได้รับการอัปเดต เพื่อให้เราสามารถอ้างอิงถึงแท็กนั้นในการเรียกใช้ไปป์ไลน์ในภายหลัง

ไปป์ไลน์ตามกำหนดเวลา

ครึ่งชั่วโมง

ไปป์ไลน์ตามกำหนดเวลาจะดำเนินการบางอย่างทุก ๆ ครึ่งชั่วโมง:

  • การอัปเดตเทมเพลต CI จากที่เก็บเทมเพลต (ในกรณีที่เปิดใช้งานผ่าน .ci/config )
  • ตรวจสอบว่าแท็กที่กำหนดเวลาไว้ไม่มีอยู่หรือกำหนดเวลาไม่ได้ชี้ไปที่ HEAD (ในกรณีนี้จะยกเลิกภารกิจ!)
  • ตรวจสอบว่า .state worktree ที่มีสถานะของแพ็คเกจอยู่หรือไม่ หากมี ก็จะตั้งค่าไว้ มิฉะนั้น มันจะสร้างมันขึ้นมาใหม่ตั้งแต่ต้น (เช่น เมื่อกดแบบบังคับ)
  • ตรวจสอบว่าการคอมมิตครั้งล่าสุดเป็นแบบอัตโนมัติหรือไม่ (ประกอบด้วย "chore(packages): อัพเดตแพ็คเกจ [skip ci]") หากใช่ การคอมมิตที่เกิดจากกำหนดการจะเขียนทับมันเพื่อรักษาประวัติการคอมมิตให้สะอาด
  • รวบรวมการประทับเวลา AUR ของแพ็คเกจเพื่อตรวจสอบว่า PKGBUILD มีการเปลี่ยนแปลงหรือไม่
  • วนซ้ำแต่ละแพ็คเกจที่ถูกต้องและดำเนินการต่อไปนี้:
    • อ่านไฟล์ .CI/config เพื่อรับข้อมูลเกี่ยวกับการกำหนดค่าแพ็คเกจ (เช่น จะจัดการพื้นที่เก็บข้อมูล AUR แหล่งที่มาของ PKGBUILD หรือไม่ เป็นต้น)
    • อัพเดต PKGBUILD ในกรณีต่อไปนี้:
      • CI_PKGBUILD_SOURCE ถูกตั้งค่าเป็น gitlab : อัปเดต PKGBUILD จากแท็กที่เก็บ GitLab
      • CI_PKGBUILD_SOURCE ถูกตั้งค่าเป็น aur : อัปเดต PKGBUILD จากที่เก็บ AUR โดยดึง repo git และแทนที่ไฟล์ที่มีอยู่ด้วยไฟล์ใหม่ หากไม่สามารถรวบรวมการประทับเวลา AUR ก่อนหน้านี้ได้ การอัปเดตแพ็กเกจจะถูกข้ามไป
      • CI_PKGBUILD_SOURCE ไม่ได้ตั้งค่าเป็น gitlab หรือ aur : พยายามอัปเดต PKGBUILD โดยการดึงที่เก็บที่ระบุใน CI_PKGBUILD_SOURCE ในกรณีที่การโคลนไม่สำเร็จหลังจากพยายามไปแล้ว 2 ครั้ง กระบวนการอัปเดตจะถูกข้ามไป
    • ในกรณีที่ CI_GIT_COMMIT ถูกตั้งค่าในตัวแปรการกำหนดค่าแพ็คเกจ การคอมมิตล่าสุดของ git URL ที่ตั้งค่าในส่วน source ของ PKGBUILD จะได้รับการอัปเดต หากแตกต่าง ให้กำหนดเวลาสร้าง
    • ในกรณีที่มี hook แบบกำหนดเอง ( .CI/update.sh ภายในไดเร็กทอรีแพ็คเกจ) จะถูกดำเนินการ - สามารถใช้สำหรับการอัพเดต PKGBUILD ด้วยสคริปต์ที่กำหนดเอง
    • การเขียนตัวแปรที่จำเป็นกลับไปที่ .CI/config (เช่น Git hash)
  • อัปเดต PKGBUILD โดยไม่ต้องแจ้งให้ทราบในกรณีที่มีการเปลี่ยนแปลงเล็กน้อย สร้าง PR เพื่อตรวจสอบในกรณีที่มีการอัปเดตหลัก (และเฉพาะในกรณีที่ CI_HUMAN_REVIEW เป็นจริง)
    • การอัปเดตจะได้รับการพิจารณาก็ต่อเมื่อความแตกต่างรายงานการเปลี่ยนแปลงระหว่างโฟลเดอร์ PKGBUILD ปัจจุบันและ repo AUR PKGBUILD จริง ๆ
    • ตรวจพบการเปลี่ยนแปลงใด ๆ ที่ทำกับไฟล์ต้นฉบับ แต่จะ ไม่ ตรวจพบการเปลี่ยนแปลงที่เป็นอันตรายในแหล่งที่มาของโปรเจ็กต์อัปสตรีมที่แพ็คเกจสร้าง
  • แผนผังงานของรัฐได้รับการอัปเดตด้วยข้อมูลใหม่
  • พารามิเตอร์กำหนดการกำลังถูกสร้างขึ้นและส่งมอบให้กับงานที่กำหนดเวลาไว้ผ่านทางส่วนต่างๆ
  • สาขาที่ล้าสมัย (เช่น PR บทวิจารณ์ที่รวมเข้าด้วยกัน) กำลังถูกตัดออก
  • แท็กที่กำหนดเวลาไว้ได้รับการอัปเดตอีกครั้ง

รายวัน

มีการเพิ่มกำหนดการไปป์ไลน์รายวันสำหรับแพ็คเกจเฉพาะที่สร้าง pkgver แบบไดนามิก หากต้องการใช้งาน ให้ตั้งค่า CI_ON_TRIGGER=daily ภายในไฟล์ .CI/config ของแพ็คเกจ

การตั้งเวลาด้วยตนเอง

การกำหนดเวลาแพ็คเกจโดยไม่ต้องคอมมิต

คุณสามารถเพิ่มแพ็คเกจลงในกำหนดการได้ด้วยตนเองโดยไปที่หน้าการรันไปป์ไลน์ เลือก "รันไปป์ไลน์" และเพิ่ม PACKAGES เป็นตัวแปรโดยมีชื่อแพ็คเกจเป็นค่า ไปป์ไลน์จะรับพัสดุและกำหนดเวลา PACKAGES สามารถตั้งค่าเป็น all เพื่อกำหนดเวลาแพ็คเกจทั้งหมดได้ ในกรณีที่มีการกำหนดเวลาแพ็กเกจหนึ่งหรือหลายแพ็กเกจ จะต้องเป็นไปตามรูปแบบ pkgname1:pkgname2:pkgname3

เรียกใช้ไปป์ไลน์ตามกำหนดเวลาตามความต้องการ

ซึ่งสามารถทำได้โดยไปที่หน้าการเรียกใช้ไปป์ไลน์ เลือก "เรียกใช้ไปป์ไลน์" (สัญลักษณ์การเล่น) จะมีการจัดเตรียมลิงก์ไปยังหน้าไปป์ไลน์ ซึ่งสามารถรับบันทึกไปป์ไลน์ได้

เข้ามารบกวนเพิ่ม.

ใส่ไฟล์รบกวนที่จำเป็นลงในโฟลเดอร์ .CI ของโฟลเดอร์ PKGBUILD:

  • prepare : สคริปต์ที่กำลังดำเนินการหลังจากตั้งค่า chroot ของอาคารแล้ว สามารถใช้เพื่อแหล่งที่มาของตัวแปรสภาพแวดล้อมหรือแก้ไขสิ่งอื่น ๆ ก่อนที่จะเริ่มการคอมไพล์
    • หากจำเป็นต้องตั้งค่าบางอย่างก่อนกระบวนการคอมไพล์จริง คำสั่งสามารถพุชได้โดยการแทรก เช่น $CAUR_PUSH 'source /etc/profile' ในทำนองเดียวกัน ข้อขัดแย้งของแพ็คเกจสามารถแก้ไขได้ เช่น ดังต่อไปนี้: $CAUR_PUSH 'yes | pacman -S nftables' (เครื่องหมายคำพูดเดี่ยวมีความสำคัญเนื่องจากเราต้องการให้ตัวแปร/ไปป์ประเมินในรันไทม์ของแขกและไม่รบกวน)
  • interfere.patch : ไฟล์แพทช์ที่สามารถใช้เพื่อแก้ไขหลายไฟล์หรือ PKGBUILD หากจำเป็นต้องเปลี่ยนแปลงจำนวนมาก จำเป็นต้องเพิ่มการเปลี่ยนแปลงทั้งหมดลงในไฟล์นี้
  • PKGBUILD.prepend : เนื้อหาของไฟล์นี้จะถูกเพิ่มที่จุดเริ่มต้นของ PKGBUILD
  • PKGBUILD.append : เนื้อหาของไฟล์นี้จะถูกเพิ่มต่อท้าย PKGBUILD การแก้ไข build() นั้นง่ายดายเหมือนกับการเพิ่ม fix build() ลงในไฟล์นี้ สามารถใช้สำหรับการแก้ไขทุกประเภท หากจำเป็นต้องเพิ่มบางสิ่งลงในอาร์เรย์ makedepend+=(somepackage) ก็ทำได้ง่ายพอๆ กัน
  • on-failure.sh : สคริปต์ที่กำลังดำเนินการหากบิลด์ล้มเหลว
  • on-success.sh : สคริปต์ที่กำลังดำเนินการหากบิลด์สำเร็จ

กระแทก pkgrel

ขณะนี้ดำเนินการโดยการเพิ่มตัวแปร CI_PACKAGE_BUMP ที่จำเป็นลงใน .CI/config ดูด้านล่างสำหรับข้อมูลเพิ่มเติม

ต้นไม้ที่ต้องพึ่งพา

CI สร้างแผนผังการพึ่งพาโดยอัตโนมัติ สิ่งเหล่านี้จะถูกส่งไปยัง Chaotic Manager ในรูปแบบ CI และอ่านทุกครั้งที่มีการดำเนินการคำสั่งกำหนดการ ไม่จำเป็นต้องมีการแทรกแซงด้วยตนเอง

.CI/การกำหนดค่า

ไฟล์ .CI/config ภายในแต่ละไดเร็กทอรีแพ็คเกจประกอบด้วยแฟล็กเพิ่มเติมเพื่อควบคุมไปป์ไลน์และสร้างกระบวนการด้วย

  • CI_MANAGE_AUR : โดยการตั้งค่าตัวแปรนี้เป็น true CI จะอัปเดตที่เก็บ AUR ที่เกี่ยวข้องเมื่อสิ้นสุดการรันไปป์ไลน์หากมีการเปลี่ยนแปลงเกิดขึ้น (ละเว้นไฟล์ที่เกี่ยวข้องกับ CI)
  • CI_PACKAGE_BUMP : ควบคุมการกระแทกของแพ็คเกจสำหรับแพ็คเกจทั้งหมดที่ไม่ได้ตั้งค่า CI_MANAGE_AUR ให้เป็น true โดยจะเพิ่ม pkgrel 0.1 ทุกๆ +1 ที่เพิ่มขึ้นของตัวแปรนี้
  • CI_PKGBUILD_SOURCE : ตั้งค่าแหล่งที่มาสำหรับไฟล์ที่เกี่ยวข้องกับ PKGBUILD ทั้งหมด ซึ่งใช้สำหรับดึงไฟล์ที่อัพเดตจากที่เก็บระยะไกล ค่าที่ถูกต้อง ณ ขณะนี้คือ:
    • gitlab : ดึง PKGBUILD จากแท็กที่เก็บ GitLab จะต้องเป็นไปตามรูปแบบ gitlab:$PROJECT_ID สามารถรับ ID ได้โดยการเรียกดูส่วนทั่วไปของการตั้งค่าพื้นที่เก็บข้อมูล
    • aur : ดึง PKGBUILD จากที่เก็บ AUR ดึง repo git และแทนที่ไฟล์ที่มีอยู่ด้วยไฟล์ใหม่
  • CI_ON_TRIGGER : สามารถระบุได้ในกรณีที่ทริกเกอร์กำหนดการพิเศษควรกำหนดเวลาแพ็คเกจที่เกี่ยวข้อง สามารถใช้กำหนดเวลาแพ็กเกจรายวันได้โดยตั้งค่าเป็น daily เนื่องจากสิ่งนี้จะตรวจสอบว่า "$TRIGGER == $CI_ON_TRIGGER" จึงสามารถสร้างกำหนดการที่กำหนดเองได้โดยใช้กำหนดการไปป์ไลน์และตั้งค่า TRIGGER เป็น midnight เพิ่มกำหนดการที่เหมาะสมและการตั้งค่า CI_ON_TRIGGER สำหรับแพ็คเกจที่ได้รับผลกระทบใด ๆ ถึง midnight
  • CI_REBUILD_TRIGGERS : เพิ่มแพ็คเกจที่ทราบว่าทำให้เกิดการสร้างตัวแปรนี้ใหม่ รายการที่เก็บเพื่อติดตามเวอร์ชันแพ็กเกจมีให้ผ่านพารามิเตอร์ CI_LIB_DB ของที่เก็บ แต่ละเวอร์ชันของแพ็คเกจจะถูกแฮชและทิ้งไปที่ .ci/lib.state การเรียกใช้ไปป์ไลน์ตามกำหนดการแต่ละครั้งจะเปรียบเทียบเวอร์ชันโดยตรวจสอบแฮชที่ไม่ตรงกัน และจะชนแต่ละแพ็กเกจที่ได้รับผลกระทบผ่าน CI_PACKAGE_BUMP
  • BUILDER_CACHE_SOURCES : สามารถตั้งค่าเป็น true ในกรณีที่ควรแคชแหล่งที่มาระหว่างบิลด์ สิ่งนี้มีประโยชน์ในกรณีที่แหล่งที่มาช้าหรือแหล่งที่มาที่ไม่พร้อมใช้งานตลอดเวลา แหล่งที่มาจะถูกล้างโดยอัตโนมัติหลังจากผ่านไป 1 เดือน ซึ่งเป็นสิ่งสำคัญในกรณีที่แพ็คเกจถูกลบออกหรือมีการเปลี่ยนแปลงแหล่งที่มา

การจัดการแพ็คเกจ AUR

แพ็คเกจ AUR สามารถจัดการผ่านพื้นที่เก็บข้อมูลนี้ด้วยวิธีอัตโนมัติโดยใช้ . .CI_CONFIG ซึ่งหมายความว่าหลังจากแต่ละไปป์ไลน์ตามกำหนดเวลาและตามการคอมมิต พื้นที่เก็บข้อมูล AUR จะได้รับการอัปเดตเพื่อแสดงการเปลี่ยนแปลงที่ทำกับไฟล์ของโฟลเดอร์ PKGBUILD ไฟล์ที่ไม่เกี่ยวข้องกับการบำรุงรักษา AUR (เช่น โฟลเดอร์ .CI ) จะถูกละเว้น ข้อความคอมมิตสะท้อนถึงข้อเท็จจริงที่ว่าคอมมิตนั้นถูกสร้างขึ้นโดยไปป์ไลน์ CI และมีลิงก์ไปยังประวัติคอมมิตของแหล่งเก็บข้อมูลต้นทางและการทำงานของไปป์ไลน์ซึ่งทริกเกอร์คอมมิตการอัปเดต

การอัปเดตสคริปต์ของ CI

ซึ่งจะดำเนินการโดยอัตโนมัติผ่านไปป์ไลน์ CI เมื่อตรวจพบการเปลี่ยนแปลงในที่เก็บเทมเพลต ไฟล์ทั้งหมดจะได้รับการอัปเดตเป็นเวอร์ชันปัจจุบัน

ปัญหาและความล้มเหลวไปป์ไลน์

ไปป์ไลน์ที่คอมมิตครั้งล่าสุดล้มเหลว

กรณีนี้อาจเกิดขึ้นได้ในกรณีด้วยเหตุผลบางประการ เช่น ระบุชื่อแพ็กเกจไม่ถูกต้อง ซึ่งทำให้แท็ก scheduled ไม่ได้รับการอัปเดต ในกรณีนี้ ไปป์ไลน์ตามกำหนดเวลาจะไม่สามารถทำงานได้ ไปป์ไลน์ตามกำหนดเวลาสุดท้ายจะต้องได้รับการแก้ไขก่อนที่ไปป์ไลน์ตามกำหนดเวลาจะสามารถทำงานได้อีกครั้ง อย่างไรก็ตาม ความล้มเหลวของบิลด์จะไม่ถูกนำมาพิจารณา เนื่องจากแท็ก scheduled จะได้รับการอัปเดตทันทีที่สร้างพารามิเตอร์การกำหนดเวลา การบังคับให้ผลักดันการคอมมิตแบบคงที่นั้นได้รับการสนับสนุนอย่างแข็งขันในกรณีเช่นนี้ เนื่องจากการผลักคอมมิตอื่นจะทำให้ CI ประเมินการคอมมิตก่อนหน้านี้ที่พลาดไป ซึ่งนำไปสู่การสังเกตเห็นปัญหาเดิมอีกครั้งและประกันตัวออกไปแทนที่จะดำเนินการต่ออย่างเงียบๆ นี่เป็นการตัดสินใจออกแบบเพื่อป้องกันไม่ให้มองข้ามความล้มเหลว

กำลังรีเซ็ตคิวบิลด์

อาจมีบางกรณีที่จำเป็นต้องรีเซ็ตคิวบิลด์ซึ่งเกิดขึ้นไม่บ่อยนัก ซึ่งสามารถทำได้โดยการปิดอินสแตนซ์ Redis ส่วนกลาง ลบดัมพ์ออก และรีสตาร์ทบริการ

ผู้จัดการวุ่นวาย

เครื่องมือนี้แจกจ่ายเป็นคอนเทนเนอร์ Docker และประกอบด้วยอินสแตนซ์ตัวจัดการและตัวสร้างคู่กัน

  • ผู้จัดการ: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
  • ตัวสร้าง: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
    • อันนี้มีตรรกะที่แท้จริงเบื้องหลังการสร้างแพ็คเกจ (ดูที่นี่) ที่รู้จักจาก infra 3.0 เช่น interfere.sh , database.sh เป็นต้น
    • เลือกแพ็คเกจที่จะสร้างจากอินสแตนซ์ Redis ที่จัดการโดยอินสแตนซ์ตัวจัดการ

GitLab CI ใช้ตัวจัดการในงาน schedule-package โดยเพิ่มลงในคิวบิลด์ ตัวสร้างสามารถใช้งานได้กับเครื่องใดก็ได้ที่สามารถใช้งานคอนเทนเนอร์ได้ มันจะเลือกงานที่ว่างจากอินสแตนซ์ Redis ส่วนกลางของเรา

การตั้งค่าการพัฒนา

พื้นที่เก็บข้อมูลนี้มีเกล็ด NixOS ซึ่งอาจใช้ในการตั้งค่าสิ่งที่จำเป็น เช่น ตะขอและการตรวจสอบล่วงหน้า รวมถึงยูทิลิตี้ที่จำเป็นโดยอัตโนมัติผ่าน direnv ซึ่งรวมถึงการตรวจสอบ PKGBUILD ผ่าน shellcheck และ shfmt จำเป็นต้องมี nix (ตัวจัดการแพ็คเกจ) และ direnv หลังจากนั้นสภาพแวดล้อมอาจถูกป้อนโดยการรัน direnv allow

ขยาย
ข้อมูลเพิ่มเติม
แอปที่เกี่ยวข้อง
แนะนำสำหรับคุณ
ข้อมูลที่เกี่ยวข้อง ทั้งหมด