Praktik: Membuat CI Pertama dengan GitHub Actions

Setelah memahami konsep dasar dan anatomi pipeline, saatnya praktik. Kita akan pakai aplikasi demo task-tracker-api — REST API sederhana untuk mencatat task, dibangun pakai Express, dengan beberapa test pakai Jest. Aplikasi ini sengaja dibuat simpel, karena fokus kita bukan ke aplikasinya, tapi ke pipeline CI/CD di sekelilingnya.

Target artikel ini: setiap kali kita push kode atau membuka pull request, GitHub Actions otomatis menginstall dependency dan menjalankan test kita.

Setup Repository

Langkah-langkahnya:

Buka folder demo-app di terminal.

Inisialisasi git dan buat commit pertama:

   cd demo-app
   git init
   git add .
   git commit -m "Initial commit: task-tracker-api"
   git branch -M main
   

Buat repository baru di GitHub (lewat web atau gh repo create), lalu hubungkan dan push:

   git remote add origin https://github.com/<username>/task-tracker-api.git
   git push -u origin main
   

Perhatikan, folder demo-app ini yang menjadi root dari repository-nya — bukan seluruh folder course. Jadi package.json ada persis di root repo.

Anatomi File Workflow

GitHub Actions membaca semua file .yml di dalam folder .github/workflows/. Nama filenya bebas, yang penting lokasinya benar. Mari kita bangun ci.yml bagian demi bagian.

Bagian name:

name: CI

Ini cuma nama workflow, muncul di tab Actions supaya gampang dikenali. Bagian on — trigger:

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

Ingat konsep trigger dari artikel sebelumnya? Di sini kita bilang: jalankan workflow ini kalau ada push ke branch main, ATAU kalau ada pull request yang menyasar branch main. Bagian jobs — struktur job dan step:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

Beberapa bagian penting untuk dipahami:

test: — nama job, bebas kita tentukan sendiri.

runs-on: ubuntu-latest — ini runner-nya, komputer virtual Ubuntu yang disediakan GitHub gratis.

steps: — daftar langkah yang dijalankan berurutan di dalam job ini.

uses: vs run: — uses memanggil action siap pakai dari marketplace (kode yang dibuat orang lain/GitHub, contoh: actions/checkout untuk clone kode kita ke runner). run menjalankan perintah shell biasa.

actions/checkout@v4 — WAJIB ada di hampir semua workflow, karena runner-nya mulai dari kosong, jadi kita perlu "checkout" alias ambil kode kita dulu.

actions/setup-node@v4 — install Node.js versi tertentu di runner, plus cache: 'npm' supaya install dependency lebih cepat di run berikutnya.

npm ci — mirip npm install tapi lebih cocok untuk CI: install persis sesuai package-lock.json, lebih cepat dan konsisten.

npm test — perintah yang sudah kita definisikan di package.json, menjalankan Jest.

Ini pattern yang akan kamu lihat berulang-ulang: checkout, setup runtime, install dependency, jalankan perintah.

Push dan Lihat Pipeline Jalan

git add .github/workflows/ci.yml
git commit -m "Add CI workflow"
git push

Begitu kita push, langsung buka tab Actions di repository GitHub. Kita akan melihat workflow run baru muncul dengan status kuning (running), lalu berubah hijau (success) kalau semua step lolos.

Di halaman run, klik run yang sedang jalan, lihat job test, lalu expand tiap step untuk melihat log real-time. Durasi tiap step ditampilkan, dan log npm test menunjukkan output Jest yang sama seperti kalau dijalankan lokal.

Ini yang keren dari CI: kita mendapat bukti objektif dan konsisten bahwa kode kita jalan, bukan cuma percaya omongan "di laptop saya sih jalan".

Simulasi Pipeline Gagal & Cara Debug

Sekarang mari kita coba simulasi kegagalan, karena ini yang paling sering bikin pemula panik. Coba ubah salah satu assertion di test jadi salah:

// Sengaja diubah untuk demo kegagalan
expect(res.statusCode).toBe(999); // harusnya 200

git add .
git commit -m "demo: sengaja bikin test gagal"
git push

Perhatikan, run-nya sekarang merah (failed). Klik run itu, expand step "Run tests", dan kita akan melihat persis Jest memberi tahu assertion mana yang gagal dan di baris mana. Proses debug-nya sama persis seperti debug test di lokal — bedanya, ini menyelamatkan kita dari commit rusak yang ter-merge ke main.

Setelah selesai, revert perubahan tadi:

git revert HEAD
git push

Kita revert commit rusak tadi, push lagi, dan run-nya kembali hijau.

Branch Protection — Wajibkan CI Lolos Sebelum Merge

Terakhir, kita hubungkan ini ke konsep branching strategy dari artikel sebelumnya. Percuma punya CI kalau orang masih bisa merge PR walau CI-nya merah. Karena itu kita perlu mengaktifkan branch protection.

Langkahnya:

Masuk ke Settings → Branches → Add branch protection rule.

Branch name pattern: main.

Centang "Require status checks to pass before merging", lalu pilih job test dari workflow CI kita.

Simpan.

Sekarang, PR ke branch main tidak bisa di-merge kalau job test di CI belum hijau. Ini yang membuat main selalu dalam kondisi deployable, sesuai prinsip trunk-based yang sudah dibahas sebelumnya.

Rangkuman

Kita baru saja membuat pipeline CI pertama: checkout, setup Node, install dependency, jalankan test — otomatis tiap push dan PR. Kita juga sudah melihat cara membaca log kegagalan dan mengunci branch main lewat branch protection.