Belajar GitHub Actions - Manajemen Job Dependencies & Conditional Execution

#Pendahuluan

Di episode 5 sebelumnya kita membahas variabel, contexts, dan environment variables — bagaimana data mengalir di dalam sebuah job. Namun pipeline di dunia nyata hampir tidak pernah hanya berisi satu job. Tim produksi biasanya memisahkan pekerjaan menjadi beberapa tahap: lint, build, test, dan deploy. Pertanyaan yang langsung muncul: apakah semua tahap itu berjalan bersamaan? Haruskah deploy menunggu test selesai? Bagaimana kalau hanya ingin mengirim notifikasi ketika semuanya gagal?

Jawaban untuk semua pertanyaan itu ada di episode ini: job dependencies dengan needs dan conditional execution dengan if. Kedua mekanisme ini adalah "tata lalulintas" sebuah workflow — tanpa keduanya, job-job kalian berjalan tanpa urutan dan tanpa kontrol, seperti kendaraan di persimpangan tanpa lampu merah.

#Pembahasan Utama

#Job Paralel: Perilaku Default

Default dari GitHub Actions adalah paralel. Ketika kalian mendefinisikan dua job tanpa relasi apa pun, GitHub langsung menjalankan keduanya di runner yang berbeda pada saat yang bersamaan.

name: CI
on: [push]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

Tanpa needs, job lint dan test tidak saling menunggu. Ini bagus untuk efisiensi: total waktu pipeline sama dengan durasi job terlama, bukan jumlah semua job. Analoginya seperti beberapa chef di dapur — masing-masing memasak menu berbeda secara bersamaan, bukan bergiliran.

#Mengatur Urutan Eksekusi dengan needs

Untuk membuat job berurutan, gunakan needs. Key ini mendeklarasikan job apa saja yang harus sukses terlebih dahulu sebelum job ini dimulai.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: npm ci
      - run: npm run build
  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - run: ./deploy.sh

Di sini deploy hanya mulai setelah build selesai. Ada dua hal penting:

• Urutan eksekusi: job yang direferensikan needs dijalankan lebih dulu.
• Akses data: lewat context needs, job turunan bisa membaca output job sebelumnya, misalnya needs.build.outputs.version — pola yang sering dipakai untuk meneruskan versi build ke tahap deploy.

#Conditional Execution dengan if

Tidak semua job atau step harus selalu dijalankan. Key if memungkinkan kalian mengeksekusi job atau step hanya ketika kondisi tertentu terpenuhi. Kondisi ditulis sebagai expression yang dievaluasi menjadi nilai boolean.

Kondisi default sebuah job atau step adalah sukses — ia hanya berjalan jika semua langkah sebelumnya sukses. Dengan if, kalian bisa menyimpang dari default ini menggunakan status function bawaan:

#Contoh: Notifikasi Hanya Saat Pipeline Gagal

Status function failure() sangat berguna untuk job notifikasi. Kalian tidak ingin membombardir tim dengan pesan "pipeline sukses" — pesan hanya dibutuhkan saat ada yang rusak:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: npm ci
      - run: npm run build
  notify:
    runs-on: ubuntu-latest
    needs: build
    if: failure()
    steps:
      - name: Kirim alert ke chat
        run: curl -s -X POST https://api.example.com/alert

Job notify hanya berjalan ketika build gagal. Ini adalah pola kanonis untuk integrasi dengan Slack, Telegram, atau monitoring internal.

#Contoh: Deploy Hanya dari Branch Main

Kondisi yang paling sering dipakai di produksi adalah "hanya deploy dari branch main". Caranya dengan membandingkan context github.ref, yang berisi ref lengkap branch saat ini:

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - run: ./deploy.sh production

Dengan cara ini, push ke branch lain (misalnya staging atau branch fitur) tetap menjalankan build dan test, tetapi tidak akan pernah menyentuh produksi.

#Workflow Lengkap: Kombinasi needs dan if

Sekarang mari gabungkan semuanya dalam satu workflow yang mencerminkan pipeline produksi sungguhan:

name: Deploy Pipeline
on:
  push:
    branches: [main, staging]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
  test:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - run: npm test
  deploy:
    runs-on: ubuntu-latest
    needs: [build, test]
    if: github.ref == 'refs/heads/main'
    steps:
      - run: ./deploy.sh production
  notify:
    runs-on: ubuntu-latest
    needs: [build, test, deploy]
    if: failure()
    steps:
      - run: ./alert.sh "Pipeline gagal"

Alurnya mudah dibaca: build lalu test berurutan, deploy menunggu keduanya dan hanya untuk main, sedangkan notify baru bicara ketika ada yang gagal. Perhatikan bahwa needs bisa menerima daftar beberapa job sekaligus.

#Kesalahan Umum

#Penutup

Kita telah menutup bab "kontrol alur" dari GitHub Actions:

• Job default paralel — hemat waktu, tapi ingat job terpisah total satu sama lain.
• needs — menentukan urutan eksekusi dan membuka akses output antar job.
• if + status functions — success(), failure(), always(), cancelled() untuk mengeksekusi sesuatu hanya pada kondisi yang diinginkan.
• Pola produksi — deploy hanya dari main, notifikasi hanya saat gagal.

Di episode 7 selanjutnya, kita akan belajar Dynamic Matrix Testing (Matrix Strategy) — cara menguji aplikasi di banyak kombinasi sistem operasi dan versi bahasa pemrograman hanya dari satu definisi job. Ini trik yang langsung memangkas baris-baris workflow kalian secara drastis!