คู่มือทางเทคนิค

GitLab CI

การบูรณาการอย่างต่อเนื่อง (CI) เป็นวิธีการทดสอบ สร้าง และตรวจสอบโค้ดของคุณโดยอัตโนมัติทุกครั้งที่มีการเปลี่ยนแปลง

GitLab มีคุณสมบัติ CI/CD ในตัวผ่านไฟล์ .gitlab-ci.yml ไฟล์นี้วางอยู่ในรูทของที่เก็บของคุณ จะบอก GitLab ถึงวิธีสร้างและทดสอบโปรเจ็กต์ของคุณ โดยจะกำหนดขั้นตอนและสคริปต์ที่ทำงานในสภาพแวดล้อมที่สะอาดทุกครั้งที่มีการพุชการเปลี่ยนแปลง

เอกสารนี้สรุปวิธีการทำงานของไปป์ไลน์ GitLab CI/CD ของ Lumi รวมถึงบทบาทของไฟล์ .gitlab-ci.yml, เชลล์สคริปต์ และเครื่องมือภายนอก เช่น Meson และ Ninja

สำหรับเอกสารทางเทคนิคโดยละเอียดของกระบวนการสร้าง Lumi CI โปรดดู README-CI.md ในพื้นที่เก็บข้อมูล

พื้นฐาน GitLab CI/CD

CI ถูกควบคุมโดยไฟล์ชื่อ .gitlab-ci.yml ไฟล์นี้กำหนด:

  • ขั้นตอน: กลุ่มงานที่เรียงลำดับ (เช่น build-this, build-that, package-up)
  • งาน: งานเดี่ยวที่ต้องทำในแต่ละด่าน
  • สคริปต์: คำสั่งเชลล์ที่ดำเนินการสำหรับแต่ละงาน
  • นักวิ่ง: คอมพิวเตอร์ที่ GitLab ใช้เพื่อรันงานที่กำหนดไว้ในไปป์ไลน์

ใน Lumi ขั้นตอนไปป์ไลน์คือ:

  • dependencies
  • build lumi
  • appimage

งานสร้างบนคอนเทนเนอร์

ไปป์ไลน์ Lumi ใช้คอนเทนเนอร์สำหรับบิลด์ที่สอดคล้องกัน:

  1. การสร้าง Build Container: ขั้นตอนแรกใช้ Buildah เพื่อสร้างอิมเมจ Docker ที่มีการขึ้นต่อกันทั้งหมด
  2. การใช้คอนเทนเนอร์: ขั้นตอนต่อมาจะทำงานภายในคอนเทนเนอร์นี้ เพื่อให้มั่นใจว่ามีสภาพแวดล้อมที่สอดคล้องกัน
  3. โครงสร้างที่ทำซ้ำได้: การแยกคอนเทนเนอร์รับประกันผลลัพธ์ที่เหมือนกันสำหรับนักวิ่งที่แตกต่างกัน

แนวทางนี้ช่วยให้แน่ใจว่าบิลด์ทำงานในลักษณะเดียวกันบน GitLab runner และจัดเตรียมสภาพแวดล้อมที่มีการควบคุมสำหรับกระบวนการสร้างที่ซับซ้อน

แหล่งอ้างอิงแบบรวม

อิมเมจการพึ่งพา CI ของ Lumi สร้างสแต็กแยกจาก แหล่งรวมใน repo (ไม่ใช่โคลนภายนอก):

  • lumi-babl/ (BABL)
  • lumi-gegl/ (GEGL)
  • lumi-gtk3/ (GTK3)

ไดเรกทอรีเหล่านี้จะถูกคัดลอกลงในบริบทการสร้างคอนเทนเนอร์และคอมไพล์ลงในคำนำหน้าการขึ้นต่อกัน (โดยทั่วไปคือ /opt/lumi-deps) ซึ่งจะทำให้ CI สามารถทำซ้ำได้และรับประกันว่า AppImage build จะใช้แหล่งที่มาของความจริงเดียวกันกับการพัฒนาในเครื่อง

บทบาทของเชลล์สคริปต์

โดยทั่วไปงานใน .gitlab-ci.yml จะเรียกใช้คำสั่งเชลล์โดยตรง การดำเนินการที่ซับซ้อนมักจะถูกย้ายไปยังสคริปต์ที่แยกจากกันซึ่งจัดเก็บไว้ในที่เก็บ

Lumi CI ใช้เชลล์สคริปต์แบบโมดูลาร์เพื่อจัดระเบียบตรรกะของบิลด์:

ตัวอย่างการเรียกใช้สคริปต์:

script:
  - bash build/linux/appimage/lumi-goappimage.sh 2>&1 | tee appimage_creation.log

ประโยชน์ของแนวทางนี้:

  • ล้าง YAML: เก็บไฟล์ .gitlab-ci.yml เน้นไปที่โครงสร้างงาน
  • การบำรุงรักษา: ตรรกะที่ซับซ้อนนั้นง่ายต่อการแก้ไขและแก้ไขในเชลล์สคริปต์
  • การนำกลับมาใช้ใหม่ได้: สคริปต์สามารถใช้ได้ในบริบทหรือสภาพแวดล้อมที่แตกต่างกัน
  • ความเป็นโมดูล: สามารถแยกแง่มุมต่างๆ ของบิวด์ออกเป็นสคริปต์ที่เน้นได้

สิ่งนี้ทำให้การกำหนดค่า CI สะอาดในขณะที่อนุญาตให้มีกระบวนการสร้างที่ซับซ้อน

บูรณาการกับระบบการสร้าง

Lumi ใช้ Meson และ Ninja เพื่อจัดเตรียมและสร้างโค้ด

ตัวอย่างเช่น:

script:
  - meson setup _build-${CI_RUNNER_TAG} -Dprefix="${LUMI_PREFIX}"
  - ninja -C _build-${CI_RUNNER_TAG}
  - ninja -C _build-${CI_RUNNER_TAG} install

ที่นี่:

  • meson setup เตรียมไดเร็กทอรี build และสร้าง build.ninja
  • ninja รันคำสั่ง build ตามที่กำหนดไว้

โครงสร้างระบบสร้างเมสัน

ระบบบิลด์ Meson ใช้ไฟล์รูท meson.build ที่วางอยู่ที่ไดเร็กทอรีรูทของโปรเจ็กต์ ไฟล์นี้กำหนดการกำหนดค่าบิลด์ระดับบนสุดและจุดเริ่มต้นสำหรับกระบวนการบิลด์- โดยทั่วไปแล้ว root meson.build จะอยู่ในไดเรกทอรีเดียวกันกับ .gitlab-ci.yml

  • จากนั้น จะเรียงซ้อนซ้ำ ลงในไดเร็กทอรีย่อย ซึ่งแต่ละไดเร็กทอรีอาจมีไฟล์ meson.build ของตัวเอง
  • ไฟล์ไดเร็กทอรีย่อยเหล่านี้กำหนดเป้าหมาย แหล่งที่มา การขึ้นต่อกัน และคำแนะนำในการสร้างที่เกี่ยวข้องกับไดเร็กทอรีนั้น

ตัวแปรสภาพแวดล้อม

ตัวแปรสำคัญในไปป์ไลน์ของ Lumi ได้แก่:

variables:
  DEBIAN_FRONTEND: "noninteractive"  # Prevents interactive prompts
  DEB_VERSION: "trixie"              # Debian version for consistency
  CI_RUNNER_TAG: "x86_64"            # Architecture specification

ตัวแปรเฉพาะงาน:

build-lumi:
  variables:
    COMPILER: "clang"                                           # Compiler selection
    LINKER: "lld"                                               # Linker selection
    LUMI_PREFIX: "${CI_PROJECT_DIR}/_install-${CI_RUNNER_TAG}"  # Installation path
    DEPS_PREFIX: "/opt/lumi-deps"                               # Prebuilt dependency prefix
    MESON_OPTIONS: "-Dpkgconfig.relocatable=true -Drelocatable-bundle=yes"  # Build configuration

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

โครงสร้างตัวอย่าง 

project-root/
├── .gitlab-ci.yml
├── meson.build              <-- Root Meson file
├── src/
│   ├── meson.build          <-- Subdirectory Meson file
│   └── some_source.c
├── data/
│   ├── meson.build
│   └── icons/

ในโครงสร้างนี้:

  • ไฟล์รูท meson.build กำหนดค่าสภาพแวดล้อมบิลด์โดยรวม
  • ไดเรกทอรีย่อยไฟล์ meson.build จัดการรายละเอียดการคอมไพล์สำหรับส่วนประกอบหรือโมดูลเฉพาะ
  • เค้าโครงแบบลำดับชั้นนี้ช่วยให้สร้างตรรกะแบบแยกส่วนและบำรุงรักษาได้

สิ่งประดิษฐ์ระหว่างด่าน

อาร์ติแฟกต์คือไฟล์ที่สร้างขึ้นโดยงานที่จำเป็นในขั้นตอนต่อๆ ไป:

build-lumi:
  # ...job configuration...
  artifacts:
    paths:
      - "${LUMI_PREFIX}/"      # Installation files
      - _build-${CI_RUNNER_TAG}/meson-logs/meson-log.txt  # Build logs

ขั้นตอนไปป์ไลน์และการพึ่งพา

ไปป์ไลน์ Lumi ประกอบด้วยสามขั้นตอนหลัก:

  1. การขึ้นต่อกัน: สร้างสภาพแวดล้อมบิลด์แบบคอนเทนเนอร์พร้อมเครื่องมือและไลบรารีที่จำเป็นทั้งหมด
  2. สร้าง Lumi: รวบรวม Lumi โดยใช้ Meson และ Ninja ในสภาพแวดล้อมที่เตรียมไว้
  3. AppImage: จัดทำแพ็กเกจแอปพลิเคชันที่สร้างขึ้นให้อยู่ในรูปแบบ AppImage ที่แจกจ่ายได้

การขึ้นต่อกันของเวที:

build-lumi:
  needs: [deps-debian]  # Waits for dependency container

lumi-appimage:
  needs: [build-lumi] # Waits for application build

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

ชื่องานปัจจุบัน

Lumi .gitlab-ci.yml ปัจจุบันกำหนดชื่องานเหล่านี้:

  • deps-debian
  • build-lumi
  • lumi-appimage

สรุป

  • .gitlab-ci.yml กำหนดโครงสร้างและตรรกะของไปป์ไลน์
  • งานมีคำสั่งเชลล์หรือสคริปต์ภายนอก
  • เครื่องมืออย่าง Meson และ Ninja ถูกใช้ในงานซึ่งเป็นส่วนหนึ่งของกระบวนการสร้าง

Lumi ใช้ GitLab CI เพื่อสร้าง AppImage สำหรับแพลตฟอร์มที่ใช้ Debian โดยอัตโนมัติ ไปป์ไลน์สร้างการขึ้นต่อกัน คอมไพล์ Lumi จากนั้นทำแพ็กเกจ AppImage

สำหรับรายละเอียดระดับแหล่งที่มา ให้ใช้:

  • .gitlab-ci.yml ในรูทที่เก็บ Lumi
  • build/linux/appimage/lumi-goappimage.sh
  • build/linux/appimage/README-CI.md

หากต้องการรายละเอียดทางเทคนิคที่ครอบคลุมเกี่ยวกับกระบวนการสร้าง Lumi CI รวมถึงการตั้งค่าสภาพแวดล้อม สถาปัตยกรรมสคริปต์ และการแก้ไขปัญหา โปรดดูที่ README-CI.md

การจัดการสีการใช้ Git บน Linux