Belajar GitLab CI/CD - Dynamic Control Flow dengan rules & workflow

#Pendahuluan

Di episode 3 kalian sudah memiliki runner yang siap mengeksekusi job. Sekarang pertanyaannya: kapan sebuah job harus berjalan? Pipeline yang berjalan di setiap push tanpa kontrol akan membuang resource — dan bahkan berbahaya. Bayangkan job deploy yang jalan hanya karena ada perubahan di file README, atau pipeline ganda yang boros setiap kali kalian push ke branch yang punya merge request terbuka.

Episode ini membahas dynamic control flow: bagaimana mengendalikan kapan sebuah job ikut pipeline dan kapan keseluruhan pipeline dibuat, menggunakan rules dan workflow.

#Pembahasan Utama

#Legasi only/except vs Modern rules

Sejak lama GitLab menyediakan only dan except untuk mengontrol kapan job berjalan. Keduanya sederhana: only: [main] berarti job hanya jalan di branch main, dan except: [tags] berarti tidak jalan pada tags. Tapi batasannya nyata: sulit mengkombinasikan beberapa kondisi, tidak bisa dipakai di level workflow, dan evaluasinya kaku karena hanya mencocokkan daftar nilai statis.

rules hadir sebagai penggantinya — lebih powerful dan fleksibel:

#Sintaks Dasar rules

rules adalah daftar kondisi yang dievaluasi berurutan dari atas ke bawah. Kondisi pertama yang cocok menentukan nasib job — jika tidak ada yang cocok, default-nya job tidak ikut pipeline. Empat kondisi utamanya:

• if — kondisi berbasis variabel predefined, misal nama branch atau sumber pipeline.
• changes — berjalan hanya jika file tertentu berubah.
• exists — berjalan jika file tertentu ada di repository.
• when — keputusan akhir: jalan, gagal, manual, selalu, atau tidak sama sekali.

#Kondisi if — Berbasis Variabel

Kondisi if membandingkan variabel predefined dengan nilai tertentu. Contoh klasik: job deploy hanya muncul di branch main:

deploy_prod:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

Di sini job deploy_prod hanya muncul ketika branch yang diproses adalah main, dan berjalan setelah diklik manual. Variabel $CI_COMMIT_BRANCH berisi nama branch yang sedang diproses — ini salah satu predefined variable yang akan kita bahas tuntas di episode 5. Perhatikan juga when: manual: aturan ini menambahkan lapisan kontrol, bukan sekadar "jalan atau tidak".

#Kondisi changes — Jalankan Hanya Jika File Berubah

Kondisi changes memeriksa file mana yang berubah pada commit atau merge request:

backend_test:
  stage: test
  script:
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - src/**/*

Job backend_test hanya ikut pipeline jika pipeline berasal dari merge request event dan ada perubahan di dalam folder src. Inilah cara terbaik memangkas waktu pipeline di monorepo: README yang berubah tidak akan memicu test backend.

#Kondisi exists — Jalankan Jika File Ada

Kondisi exists mengecek keberadaan file di repository, tanpa peduli apakah file itu berubah:

deploy_helm:
  stage: deploy
  script:
    - helm upgrade --install my-app ./chart
  rules:
    - exists:
        - "**/Chart.yaml"

Job Helm di atas hanya dibuat jika repository memiliki file Chart.yaml di direktori manapun. Kondisi ini sangat cocok untuk pipeline monorepo yang menangani banyak teknologi sekaligus.

#Parameter when

Parameter when menentukan keputusan akhir setelah kondisi cocok:

Kombinasi yang paling sering dipakai di produksi — approval gate untuk deploy dan notifikasi saat gagal:

deploy_prod:
  stage: deploy
  script:
    - ./deploy.sh
  when: manual
 
notify_failure:
  stage: deploy
  script:
    - curl -X POST https://alerts.example.com/deploy-failed
  when: on_failure

deploy_prod menunggu klik manusia (approval gate), sedangkan notify_failure otomatis jalan hanya jika ada job yang gagal sebelumnya — sempurna untuk alerting ke Slack atau tool monitoring.

#workflow: rules — Mengontrol Seluruh Pipeline

Semua pembahasan di atas berfokus pada level job. Tapi terkadang kalian ingin mengontrol apakah pipeline dibuat sama sekali. Kasus klasiknya: kalian membuka merge request dari branch feature, lalu push lagi ke branch itu. GitLab akan membuat dua pipeline — satu untuk push ke branch, satu untuk merge request. Ini boros resource dan membingungkan.

Solusinya workflow: rules — aturan di level pipeline:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG
    - when: never

Pipeline hanya dibuat untuk tiga kasus: pipeline merge request, push ke default branch, dan tag. Semua kasus lain — misal push ke branch feature biasa — tidak menghasilkan pipeline, karena aturan when: never di akhir menutup semua kondisi yang tidak cocok.

#Kesalahan Umum

1. Aturan dievaluasi berurutan, bukan "terbaik". Kondisi pertama yang cocok langsung menang — urutan rules sangat menentukan. Taruh kondisi paling spesifik di paling atas.
2. Lupa penutup when: never di workflow. Tanpa penutup, pipeline tetap dibuat di luar kasus yang diizinkan, dan duplicate pipeline tidak terhindarkan.
3. Perbandingan string case-sensitive. $CI_COMMIT_BRANCH == "main" tidak akan cocok dengan branch bernama Main. Pastikan penulisan branch persis.

#Penutup

Pada episode 4 ini kalian telah menguasai kontrol alur dinamis GitLab CI/CD:

• Perbedaan only/except yang legacy vs rules modern yang lebih fleksibel dan direkomendasikan.
• Kondisi if berbasis variabel, changes untuk perubahan file, dan exists untuk keberadaan file.
• Parameter when: on_success, on_failure, always, manual, dan never.
• workflow: rules untuk mengontrol kapan keseluruhan pipeline dibuat dan mencegah duplicate pipeline.

Sekarang kalian bisa mengendalikan kapan pipeline berjalan. Di episode 5 kita akan membahas nilai yang mengalir di dalamnya — variables, masks, dan secret management: predefined variables, custom CI/CD variables, flags keamanan (protected, masked, expand), serta integrasi HashiCorp Vault langsung di .gitlab-ci.yml. Sampai jumpa di episode 5!