Memahami Komponen Dasar GitHub Actions: Workflow, Job, dan Step

Pendahuluan

Bayangkan kamu punya asisten pribadi yang setiap kali kamu menyelesaikan pekerjaan, langsung otomatis mengecek hasilnya, membungkusnya rapi, dan mengirimkannya ke tempat tujuan — tanpa kamu perlu melakukan apa pun secara manual. Itulah gambaran sederhana dari GitHub Actions.

GitHub Actions adalah platform CI/CD (Continuous Integration/Continuous Deployment) bawaan GitHub yang memungkinkan kamu mengotomatisasi hampir semua aspek dari alur kerja pengembangan software. Mulai dari menjalankan tes, memformat kode, hingga deploy ke server produksi — semua bisa berjalan sendiri.

Namun, sebelum kamu bisa memanfaatkan kekuatan penuh GitHub Actions, ada tiga konsep fundamental yang wajib kamu pahami: Workflow, Job, dan Step. Ketiga elemen ini adalah tulang punggung dari setiap otomatisasi yang kamu buat.

Di artikel ini, kita akan membahas masing-masing konsep secara mendalam dengan analogi yang mudah dipahami dan contoh kode nyata yang langsung bisa kamu coba. Jika kamu belum familiar sama sekali dengan GitHub Actions, ada baiknya membaca dulu Apa itu GitHub Actions: Penjelasan Lengkap untuk Pemula agar konteksnya lebih jelas.

Apa itu Workflow? Pintu Gerbang Otomatisasi Anda

Workflow adalah keseluruhan proses otomatisasi yang kamu definisikan. Anggap saja workflow seperti sebuah resep masakan: ia menjelaskan kapan kamu memasak (trigger), apa yang dimasak (jobs), dan bagaimana cara memasaknya (steps).

Setiap workflow disimpan sebagai file YAML di dalam direktori .github/workflows/ pada repositori kamu.

# .github/workflows/halo-dunia.yml

name: Halo Dunia Workflow   # Nama workflow kamu

on:                          # KAPAN workflow ini dijalankan?
  push:
    branches:
      - main                 # Jalankan saat ada push ke branch main

jobs:
  sapa:                      # Nama job (bisa kamu tentukan sendiri)
    runs-on: ubuntu-latest   # Sistem operasi yang digunakan
    steps:
      - name: Cetak pesan
        run: echo "Halo, dunia dari GitHub Actions!"

Bagian-bagian Utama Workflow

Jenis-jenis Trigger (on)

on:
  push:                      # Dipicu saat ada push
    branches: [main, develop]

  pull_request:              # Dipicu saat ada pull request
    branches: [main]

  schedule:                  # Dipicu secara terjadwal (cron)
    - cron: '0 6 * * *'      # Setiap hari pukul 06:00 UTC

  workflow_dispatch:         # Dipicu secara manual dari GitHub UI

Mengenal Job: Kumpulan Tugas yang Berjalan Bersama

Jika workflow adalah resep masakan, maka Job adalah setiap stasiun memasak di dapur. Kamu bisa punya stasiun untuk memotong bahan, stasiun untuk memasak, dan stasiun untuk penyajian — masing-masing berjalan di lingkungan (runner) sendiri.

Karakteristik penting Job:

1. Setiap job berjalan di runner terpisah — artinya, lingkungannya terisolasi
2. Job bisa berjalan paralel (secara bersamaan) atau sekuensial (berurutan)
3. Job bisa bergantung pada job lain menggunakan keyword needs

jobs:
  build:                     # Job pertama: build aplikasi
    runs-on: ubuntu-latest
    steps:
      - name: Build proyek
        run: echo "Membangun aplikasi..."

  test:                      # Job kedua: menjalankan tes
    runs-on: ubuntu-latest
    needs: build             # Job ini MENUNGGU job 'build' selesai dulu
    steps:
      - name: Jalankan tes
        run: echo "Menjalankan semua tes..."

  deploy:                    # Job ketiga: deploy ke server
    runs-on: ubuntu-latest
    needs: [build, test]     # Menunggu KEDUANYA selesai
    steps:
      - name: Deploy
        run: echo "Mendeploy ke produksi..."

Job Paralel vs Sekuensial

jobs:
  lint-python:               # Job ini berjalan BERSAMAAN dengan...
    runs-on: ubuntu-latest
    steps:
      - run: echo "Cek style Python..."

  lint-javascript:           # ...job ini (paralel, tidak ada 'needs')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Cek style JavaScript..."

  gabungkan-laporan:
    runs-on: ubuntu-latest
    needs: [lint-python, lint-javascript]  # Menunggu keduanya selesai
    steps:
      - run: echo "Membuat laporan gabungan..."

Jika kamu ingin membangun platform marketplace seperti Tokopedia, bayangkan job paralel ini seperti tim QA yang berbeda-beda memeriksa frontend, backend, dan keamanan secara bersamaan — jauh lebih cepat dibanding mengerjakan satu per satu.

Rincian Tugas dengan Step: Perintah Individual

Step adalah unit terkecil dari GitHub Actions. Setiap step adalah satu perintah atau tindakan yang dijalankan secara berurutan di dalam sebuah job.

Step bisa berupa dua jenis:

1. run — menjalankan perintah shell langsung
2. uses — menggunakan Action yang sudah dibuat orang lain (dari GitHub Marketplace)

jobs:
  contoh-steps:
    runs-on: ubuntu-latest
    steps:
      # Step 1: Checkout kode dari repositori
      - name: Checkout kode
        uses: actions/checkout@v4      # Menggunakan action dari marketplace

      # Step 2: Setup Python
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'       # Parameter untuk action

      # Step 3: Install dependensi
      - name: Install dependensi
        run: pip install -r requirements.txt  # Perintah shell biasa

      # Step 4: Jalankan tes
      - name: Jalankan pytest
        run: |
          pytest tests/
          echo "Tes selesai!"          # Pipe | untuk multi-baris

Variabel Lingkungan di Step

steps:
  - name: Deploy dengan environment variable
    env:
      APP_ENV: production
      API_URL: https://api.contoh.com
    run: |
      echo "Deploy ke environment: $APP_ENV"
      echo "Menghubungi API: $API_URL"

Menyimpan Output dari Satu Step ke Step Lain

steps:
  - name: Dapatkan versi aplikasi
    id: versi                          # Beri ID agar bisa direferensi
    run: echo "version=1.2.3" >> $GITHUB_OUTPUT

  - name: Gunakan versi tersebut
    run: echo "Versi yang di-deploy: ${{ steps.versi.outputs.version }}"

Contoh Kasus Nyata: Otomatisasi Tes Sederhana

Mari kita gabungkan semua konsep di atas menjadi satu workflow yang nyata — otomatisasi tes untuk proyek Node.js:

# .github/workflows/ci.yml

name: CI - Cek Kualitas Kode

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

jobs:
  test:
    name: Jalankan Unit Test
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]    # Test di dua versi Node sekaligus!

    steps:
      - name: 📥 Checkout kode
        uses: actions/checkout@v4

      - name: 🔧 Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'                 # Cache dependensi untuk lebih cepat

      - name: 📦 Install dependensi
        run: npm ci                    # Lebih deterministik dari npm install

      - name: 🧪 Jalankan tes
        run: npm test

      - name: 📊 Upload laporan coverage
        if: matrix.node-version == '20.x'   # Hanya untuk Node 20
        uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

  lint:
    name: Cek Kualitas Kode
    runs-on: ubuntu-latest
    needs: test                        # Jalankan setelah test berhasil

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20.x'
          cache: 'npm'

      - run: npm ci

      - name: 🔍 Jalankan ESLint
        run: npm run lint

Dengan workflow seperti ini, setiap kali ada push ke branch main atau develop, GitHub otomatis menjalankan semua tes di dua versi Node.js secara paralel — seperti punya tim QA yang bekerja 24 jam tanpa henti. Untuk contoh penerapan yang lebih spesifik, kamu bisa lanjut ke artikel Cara Menjalankan Tes Otomatis dengan GitHub Actions.

Troubleshooting: Error yang Sering Muncul

Error: yaml: line X: mapping values are not allowed in this context

Penyebab: Indentasi YAML yang salah atau penggunaan karakter yang tidak diizinkan (seperti titik dua tanpa quote) di dalam nilai string.

Solusi:

# SALAH - titik dua dalam string tanpa quote
name: Deploy: Production Server

# BENAR - gunakan quote jika ada karakter khusus
name: "Deploy: Production Server"

# Atau hindari karakter khusus
name: Deploy Production Server

Error: Process completed with exit code 1 pada step run

Penyebab: Perintah shell yang dijalankan di run mengembalikan kode error. Bisa karena tes gagal, perintah tidak ditemukan, atau dependensi belum terinstall.

Solusi:

steps:
  # Pastikan dependensi sudah diinstall SEBELUM menjalankan tes
  - name: Install dependensi
    run: npm ci          # Gunakan 'ci' bukan 'install' untuk konsistensi

  - name: Jalankan tes
    run: npm test

  # Jika ingin step tetap lanjut meskipun ada error (misalnya untuk laporan)
  - name: Upload laporan (tetap jalan meski tes gagal)
    if: always()         # Keyword 'always()' memaksa step ini selalu berjalan
    run: echo "Mengunggah laporan..."

Error: Error: Resource not accessible by integration pada permissions

Penyebab: Workflow tidak memiliki izin yang cukup untuk melakukan operasi tertentu, seperti membuat release atau menulis ke repositori.

Solusi:

name: Release Workflow

on:
  push:
    tags:
      - 'v*'

permissions:             # Tentukan izin secara eksplisit
  contents: write        # Izin untuk menulis ke repositori
  pull-requests: read    # Izin untuk membaca pull request

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Buat release
        run: gh release create ${{ github.ref_name }} --generate-notes
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Error: Workflow tidak terpicu meski sudah push

Penyebab: File workflow tidak berada di path yang benar, atau ada typo pada konfigurasi trigger on.

Solusi:

# Pastikan struktur direktori sudah benar
.github/
└── workflows/
    └── ci.yml          # File HARUS ada di sini, bukan di tempat lain

# Cek apakah file sudah di-commit dan di-push
git add .github/workflows/ci.yml
git commit -m "Tambahkan workflow CI"
git push origin main

# Cek konfigurasi trigger — pastikan branch name sudah benar
on:
  push:
    branches:
      - main           # Pastikan ini sesuai dengan nama branch aktual kamu
      # Bukan 'master' jika branch kamu bernama 'main'

Pertanyaan yang Sering Diajukan

Apa perbedaan antara Workflow, Job, dan Step?

Workflow adalah keseluruhan file otomatisasi yang mendefinisikan kapan sesuatu berjalan. Job adalah kelompok pekerjaan yang berjalan di satu mesin (runner) yang sama. Step adalah perintah individual di dalam sebuah job. Analoginya: Workflow = proyek, Job = departemen, Step = tugas harian seorang karyawan.

Berapa banyak Job dan Step yang bisa ada dalam satu Workflow?

GitHub Actions memperbolehkan hingga 255 job per workflow, dan setiap job bisa memiliki hingga 100 step. Namun dalam praktiknya, lebih sedikit dan lebih terfokus selalu lebih baik untuk kemudahan pemeliharaan.

Apakah GitHub Actions gratis untuk digunakan?

Untuk repositori publik, GitHub Actions sepenuhnya gratis tanpa batas. Untuk repositori privat, GitHub memberikan jatah menit gratis per bulan (tergantung paket akun kamu). Setelah jatah habis, dikenakan biaya tambahan berdasarkan penggunaan menit runner.

Bagaimana cara menyimpan data sensitif seperti API key di GitHub Actions?

Jangan pernah menulis API key atau password langsung di file workflow. Gunakan GitHub Secrets yang bisa diakses melalui Settings > Secrets and variables > Actions di repositori kamu:

steps:
  - name: Deploy ke server
    env:
      API_KEY: ${{ secrets.MY_API_KEY }}  # Ambil dari GitHub Secrets
    run: ./deploy.sh

Apa itu actions/checkout dan mengapa hampir selalu dipakai di setiap workflow?

actions/checkout@v4 adalah Action resmi dari GitHub yang bertugas men-clone kode repositori kamu ke dalam runner. Tanpa step ini, runner hanya berisi sistem operasi kosong — tidak ada kode proyek kamu di dalamnya. Itulah mengapa hampir setiap workflow dimulai dengan step ini.

Kesimpulan

Kita telah menjelajahi tiga konsep fondasi GitHub Actions yang saling berhubungan:

• Workflow — blueprint keseluruhan otomatisasi, tersimpan di .github/workflows/
• Job — unit pekerjaan yang berjalan di runner terpisah, bisa paralel atau sekuensial
• Step — perintah individual dalam sebuah job, bisa berupa run (shell) atau uses (action)

Dengan memahami ketiga konsep ini, kamu sudah punya fondasi yang kuat untuk membangun pipeline CI/CD yang sesungguhnya — mulai dari otomatisasi tes, build, hingga deployment ke berbagai lingkungan.

Selamat belajar dan terus bereksperimen! Mulailah dari workflow sederhana, tambahkan kompleksitas secara bertahap, dan jangan takut mencoba. Jika ada pertanyaan, jangan ragu untuk eksplorasi artikel-artikel lain di KamusNgoding — semua ada di sini untuk membantumu berkembang!