Belajar GitLab CI/CD - Menulis .gitlab-ci.yml Pertama & Dasar Pipeline Syntax

#Pendahuluan

Di episode 1 kalian sudah memahami arsitektur GitLab CI/CD: GitLab Server memicu, Runner mengeksekusi, dan .gitlab-ci.yml mendeskripsikan semuanya. Sekarang saatnya menulis kode pipeline pertama. Episode ini membahas anatomi file .gitlab-ci.yml dari nol — mulai dari keyword global dan definisi stages, sampai job pertama yang menjalankan build dan test, lengkap dengan cara menangani error.

Menguasai sintaks dasar ini adalah fondasi mutlak: seluruh episode berikutnya — rules, variables, Docker, hingga deployment — dibangun di atas struktur yang akan kalian pelajari sekarang.

#Pembahasan Utama

#Anatomi File .gitlab-ci.yml

.gitlab-ci.yml adalah file YAML yang diletakkan di root repository. Nama file ini sakral — GitLab secara otomatis mendeteksinya setiap kali ada push, merge request, atau tag. Jika file ini ada, GitLab membuat pipeline dan menampilkannya di tab CI/CD project.

Sebelum menulis job, ada beberapa keyword global yang mengatur perilaku pipeline secara keseluruhan:

• default — pengaturan yang berlaku untuk semua job, seperti image, before_script, atau timeout.
• stages — mendefinisikan urutan fase eksekusi pipeline.
• variables — variabel global (akan dibahas mendalam di episode 5).
• workflow — kontrol kapan pipeline dibuat (episode 4).

Jika kalian tidak mendefinisikan stages sama sekali, GitLab memakai default bawaan: .pre, build, test, deploy, .post.

Stage dengan awalan titik (.pre dan .post) adalah stage khusus: kalian tidak bisa menyebutnya di daftar stages, tapi seluruh job di dalamnya tetap berjalan di urutan yang sesuai. Untuk pipeline yang lebih eksplisit, definisikan stages sendiri:

stages:
  - build
  - test
  - deploy

Urutan di daftar ini adalah urutan eksekusi. Job yang memakai stage yang tidak terdaftar akan ditolak GitLab saat membuat pipeline.

#Menulis Job Pertama

Sebuah job adalah blok YAML yang diawali nama job dan berisi minimal stage dan script. Nama job bebas (huruf, angka, underscore), selama unik di dalam file.

unit_test:
  stage: test
  script:
    - npm test

• Nama job (unit_test) — identifier job di UI pipeline.
• stage — menentukan di fase mana job dijalankan.
• script — perintah yang dieksekusi runner.

#Inline Commands

Jika job hanya menjalankan satu perintah, tulis langsung sebagai nilai script:

unit_test:
  stage: test
  script: npm test

#Multi-line Commands

Untuk beberapa perintah berurutan, gunakan daftar YAML di bawah script:

unit_test:
  stage: test
  script:
    - echo "Menjalankan unit test"
    - npm ci
    - npm run lint
    - npm test

Tiap baris dieksekusi sebagai perintah terpisah dalam satu sesi shell yang sama — variabel yang di-set di baris pertama tetap bisa dipakai di baris berikutnya. Jika salah satu perintah mengembalikan exit code bukan nol, job langsung gagal dan perintah berikutnya tidak dieksekusi.

#Menangani Error dengan allow_failure

Terkadang ada job yang boleh gagal tanpa menghentikan pipeline — misalnya linting non-blocking atau test yang sedang flaky. Gunakan allow_failure: true:

lint:
  stage: test
  script:
    - npm run lint
  allow_failure: true

Jika job lint gagal, pipeline tetap berlanjut ke stage berikutnya. Di UI, job yang gagal dengan allow_failure: true tetap berwarna oranye (warning) — jadi masalahnya terlihat, tapi tidak memblokir rilis.

#Pipeline Hello-World Lengkap

Sekarang mari rakit semuanya menjadi pipeline nyata untuk project Node.js:

stages:
  - build
  - test
 
before_script:
  - npm ci
 
build_app:
  stage: build
  script:
    - npm run build
 
unit_test:
  stage: test
  script:
    - npm test
 
e2e_test:
  stage: test
  script:
    - npx playwright test

Ada beberapa hal penting dari contoh di atas:

• before_script berjalan sebelum script di setiap job — di sini dipakai untuk menginstall dependensi sekali pakai untuk semua job.
• Job unit_test dan e2e_test berada di stage test yang sama, sehingga keduanya berjalan paralel setelah stage build selesai.
• Alur eksekusi: build_app selesai dulu → baru unit_test dan e2e_test dimulai.

Setelah file ini di-push, kalian bisa memantau pipeline langsung dari terminal dengan glab ci status:

$ glab ci status
build_app   build    running
unit_test   test     pending
e2e_test    test     pending

#Kesalahan Umum

1. File tidak di root repository. .gitlab-ci.yml harus berada di root; jika ditaruh di subdirektori, GitLab tidak akan mendeteksinya dan pipeline tidak pernah dibuat.
2. Stage tidak terdefinisi. Job yang memakai stage: deploy padahal stages tidak menyertakannya akan ditolak GitLab dengan error chosen stage does not exist.
3. Indentasi salah. YAML menolak tab dan campuran indentasi. Selalu gunakan 2 spasi per level, dan pastikan script, stage, dan allow_failure berada di level indentasi yang sama (sejajar).

#Penutup

Pada episode 2 ini kalian telah menulis pipeline pertama yang benar-benar berjalan:

• Anatomi .gitlab-ci.yml: keyword global default, stages, variables, dan workflow.
• Default stages bawaan .pre, build, test, deploy, .post, dan cara mendefinisikan urutan stages sendiri.
• Struktur job: nama job, stage, dan script, plus perbedaan inline command dan multi-line command.
• allow_failure: true sebagai cara menangani job non-kritis tanpa menghentikan pipeline.

Sekarang pipeline kalian hidup. Di episode 3 kita akan membedah siapa yang menjalankan pipeline itu — GitLab Runner. Kita akan membahas tipe-tipe runner (shared, group, specific), jenis executor (shell, docker, kubernetes), cara registrasi runner dengan token, dan cara mengarahkan job ke runner tertentu memakai tags. Sampai jumpa di episode 3!