GitHub Actions: CI Pertamamu

Kenapa test otomatis itu penting

Tanpa CI, alur kerja tim biasanya begini: seseorang push kode, reviewer menebak-nebak apakah test masih lolos, lalu bug ketahuan di production. GitHub Actions memutus rantai itu dengan menjalankan perintahmu di server GitHub setiap kali ada event tertentu, misalnya push atau pull request dibuka. Hasilnya muncul sebagai centang hijau atau silang merah di PR. Kenapa ini powerful? Karena feedback-nya datang dalam hitungan menit, otomatis, dan tidak bergantung pada ingatan siapa pun untuk "eh, jangan lupa jalanin test".

Satu fakta yang melegakan: Actions terintegrasi penuh dengan GitHub, jadi tidak perlu server CI terpisah, tidak perlu daftar akun baru. Workflow-nya sendiri disimpan sebagai file YAML di repo, ikut ter-version control seperti kode biasa.

Anatomi sebuah workflow

Workflow tinggal di folder .github/workflows/, satu file YAML per workflow. Struktur intinya hanya empat bagian:

name: CI
on:
  push:
    branches: [main]
  pull_request:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dan test
        run: |
          npm ci
          npm test

Mari bedah. on menentukan pemicu: workflow ini jalan saat ada push ke branch main atau saat PR dibuka/diupdate. jobs berisi pekerjaan yang bisa jalan paralel; di sini cuma satu job bernama test. runs-on memilih mesin virtualnya, ubuntu-latest adalah pilihan default yang gratis dan cepat. steps adalah langkah-langkah berurutan: pertama actions/checkout@v4 mengunduh kodemu ke mesin itu, lalu run mengeksekusi perintah shell biasa.

Contoh yang lebih lengkap, CI untuk proyek Node dengan test dan lint terpisah:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint

Dua job test dan lint berjalan paralel. Kalau salah satu gagal, PR mendapat silang merah dan (kalau branch protection diaktifkan) tidak bisa di-merge sampai hijau. Sintaks uses: memanggil action buatan komunitas atau GitHub sendiri, seperti checkout dan setup-node, sedangkan run: menjalankan perintah shell apa pun. Kombinasi keduanya membuat hampir semua skenario CI bisa dirakit tanpa menulis kode baru.

Kapan dipakai dan batasannya

Pakai Actions untuk semua pemeriksaan yang harus berlaku ke semua orang: test, lint, typecheck, build. Ini melengkapi Git hooks dari modul sebelumnya: hooks memberi feedback instan di laptop, Actions menjadi penegak final yang tidak bisa dilewati dengan --no-verify.

Batasan yang perlu tahu: akun gratis mendapat 2.000 menit eksekusi per bulan dan 500 MB penyimpanan artifact. Untuk proyek kecil-menengah itu lebih dari cukup, tapi workflow yang berat (misalnya build berulang tanpa cache) bisa menghabiskannya. Tips hemat: cache dependency dengan action resmi (setup-node sudah punya opsi cache bawaan), dan jangan picu workflow di setiap push branch eksperimental kalau tidak perlu, batasi lewat branches: di bagian on.

Kesalahan umum pemula

Salah: menulis workflow tapi lupa actions/checkout di awal steps, lalu bingung kenapa npm test gagal dengan "file tidak ditemukan". Tanpa checkout, mesin virtualnya kosong. Benar: selalu mulai steps dengan - uses: actions/checkout@v4 sebelum menjalankan perintah apa pun terhadap kode.

Salah: memakai npm install di CI sehingga versi dependency bisa bergeser tiap run dan build jadi tidak reproducible. Benar: pakai npm ci yang menginstal persis sesuai lockfile. Deterministik, lebih cepat, dan memang dirancang untuk CI.