Phần 4 — Rules và Merge Request Pipelines

Series GitLab CI/CD Toàn Tập — 9 phần:

1. Phần 1 — Tổng quan: GitLab CI/CD, kiến trúc và các khái niệm

2. Phần 2 — .gitlab-ci.yml đầu tiên và Variables (predefined, UI, masked)

3. Phần 3 — Cache vs Artifacts: chiến lược và Reports

4. Phần 4 — Rules và Merge Request Pipelines ← bạn đang đọc

5. Phần 5 — GitLab Runner self-hosted: cài đặt và executors (Shell/Docker)

6. Phần 6 — Kubernetes executor: scale runner trên K8s

7. Phần 7 — include, extends, anchors — pipeline modular

8. Phần 8 — Environments, Deployments và Review Apps

9. Phần 9 — Pipeline thực tế Next.js → Docker → K8s + best practices + debug

Mở đầu

only/except là cú pháp cũ — vẫn chạy được nhưng GitLab khuyến nghị chuyển sang rules vì biểu cảm hơn nhiều (if/changes/exists kết hợp được, có when: manual, allow_failure…). Phần này hệ thống rules và sau đó giải thích 3 chế độ pipeline: branch pipeline, MR pipeline, và Pipelines for Merged Results — biết chế độ nào dùng cho usecase nào là chìa khoá để CI vừa kỹ vừa không lãng phí.

1. Rules — thay thế only/except

only/except là cú pháp cũ, vẫn dùng được nhưng GitLab khuyến nghị dùng rules vì biểu cảm hơn:

deploy-prod:
  stage: deploy
  script:
    - ./deploy.sh production
  rules:
    # Chỉ chạy thủ công trên main
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
      allow_failure: false
    # Skip mọi nhánh khác
    - when: never

deploy-review:
  stage: deploy
  script:
    - ./deploy-review.sh
  rules:
    # Tự deploy review app cho mọi MR
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    # Skip code chỉ sửa docs
    - changes:
        - "**/*.md"
      when: never

Một số trường rules: quan trọng:

• if: — biểu thức boolean với biến CI/CD.

• changes: — chạy nếu file khớp glob có thay đổi.

• exists: — chạy nếu repo có file này.

• when: — always, never, manual, on_success, on_failure, delayed.

• allow_failure: true — pipeline vẫn pass dù job fail.

2. Merge Request Pipelines & Pipelines for Merged Results

Mặc định GitLab chạy pipeline cho mỗi commit trên branch. Có 3 chế độ:

"Merged Results" là tính năng cao cấp: GitLab merge tạm source vào target rồi mới chạy CI. Đảm bảo test pass trên đúng code sau khi merge, không phải code source. Bật trong Settings → Merge requests.

test:
  stage: test
  script: pnpm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

Rule trên cho phép job chạy cả ở MR pipeline lẫn branch pipeline trên main, nhưng không trùng lặp — vì khi MR mở, GitLab tự skip branch pipeline.

Tóm tắt

Trong phần này bạn đã nắm:

• Trường rules: quan trọng: if: (biểu thức với biến CI), changes: (glob), exists: (file), when: (manual/never/always/on_success/on_failure/delayed), allow_failure.

• Pattern hay dùng: tự deploy review-app cho MR ($CI_PIPELINE_SOURCE == "merge_request_event"); deploy production manual chỉ khi có tag.

• 3 chế độ pipeline: Branch (mặc định), MR pipeline (chỉ tạo khi mở MR), Merged Results (CI chạy trên kết quả merge giả lập).

• Tránh trùng lặp pipeline: dùng rules + workflow: để chỉ có 1 trong 2 (branch hoặc MR) chạy cho mỗi push.

Trong Phần 5, ta đi vào thực hành quan trọng: cài GitLab Runner self-hosted trên Ubuntu với Docker executor — bao gồm config.toml nâng cao và S3 cache.

Phần 5: GitLab Runner self-hosted: cài đặt và executors (Shell/Docker) →