Apa itu GitHub Actions? Penjelasan Lengkap untuk Pemula

Pendahuluan

Pernahkah kamu membayangkan punya asisten pribadi yang bekerja tanpa henti — setiap kali kamu menyimpan kode baru, asisten itu otomatis menguji kode tersebut, membangun aplikasinya, lalu mengirimnya ke server produksi? Itulah, secara sederhana, apa yang dilakukan GitHub Actions.

GitHub Actions adalah platform otomasi yang terintegrasi langsung di dalam GitHub. Dengan GitHub Actions, kamu bisa membuat alur kerja otomatis (workflow) yang berjalan ketika terjadi suatu peristiwa di repositori kamu — misalnya ketika ada push kode baru, ketika ada pull request masuk, atau bahkan berdasarkan jadwal tertentu.

Bayangkan kamu sedang membangun aplikasi e-commerce seperti Tokopedia. Setiap hari ada puluhan atau ratusan perubahan kode dari berbagai developer. Tanpa otomasi, seseorang harus secara manual menguji semua perubahan itu, memastikan tidak ada bug, lalu men-deploy ke server. Dengan GitHub Actions, semua proses itu berjalan secara otomatis tanpa campur tangan manusia.

Di artikel ini, kita akan belajar dari nol — mulai dari konsep dasar CI/CD, komponen GitHub Actions, hingga membuat workflow pertama kamu sendiri.

Memahami Konsep Dasar CI/CD

Sebelum masuk ke GitHub Actions, kita perlu memahami dua istilah penting: CI dan CD.

Continuous Integration (CI)

CI adalah praktik mengintegrasikan perubahan kode secara terus-menerus ke dalam repositori bersama. Setiap kali ada kode baru yang masuk, sistem secara otomatis menjalankan serangkaian pengujian untuk memastikan kode tersebut tidak merusak fitur yang sudah ada.

Analoginya: Bayangkan sebuah pabrik roti. Setiap adonan baru yang masuk langsung dicek kualitasnya — tekstur, rasa, dan kandungannya — sebelum diproses lebih lanjut. Jika adonannya tidak lolos, langsung dikembalikan untuk diperbaiki.

Continuous Deployment/Delivery (CD)

CD adalah kelanjutan dari CI. Setelah kode berhasil melewati pengujian, kode tersebut secara otomatis dikirim ke lingkungan staging atau produksi.

Dengan CI/CD, tim developer bisa lebih percaya diri merilis fitur baru karena setiap perubahan sudah diuji secara otomatis. Jika ingin membangun layanan dengan skalabilitas tinggi seperti Gojek, CI/CD adalah pondasi yang wajib ada.

Komponen Utama GitHub Actions

GitHub Actions memiliki beberapa komponen utama yang perlu kamu pahami:

Cara mudah mengingatnya: Workflow punya beberapa Job, setiap Job punya beberapa Step, dan setiap Step bisa menjalankan satu Action. Semuanya dipicu oleh Event dan dieksekusi di Runner.

Anatomi File Workflow: Langkah demi Langkah

Semua workflow GitHub Actions disimpan dalam direktori .github/workflows/ di repositori kamu, dengan format file .yml atau .yaml.

Berikut adalah contoh file workflow sederhana beserta penjelasan setiap barisnya:

# File: .github/workflows/ci.yml

name: CI Pipeline  # Nama workflow yang akan tampil di tab Actions GitHub

on:
  push:
    branches:
      - main  # Jalankan workflow saat ada push ke branch main
  pull_request:
    branches:
      - main  # Jalankan juga saat ada pull request ke branch main

jobs:
  build-and-test:
    runs-on: ubuntu-latest  # Gunakan runner Linux terbaru dari GitHub

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4  # Mengambil isi repository agar bisa diproses

      - name: Setup Node.js
        uses: actions/setup-node@v4  # Menyiapkan Node.js di runner
        with:
          node-version: 20  # Gunakan Node.js versi 20

      - name: Install dependencies
        run: npm install  # Menginstal semua package dari package.json

      - name: Run tests
        run: npm test  # Menjalankan testing project

      - name: Build app
        run: npm run build  # Membuat hasil build aplikasi

# Output yang diharapkan:
# > Workflow "CI Pipeline" berjalan otomatis saat push atau pull request ke main
# > Semua langkah selesai dengan status sukses jika install, test, dan build berhasil

Perhatikan bagaimana setiap step bisa menggunakan uses (untuk action yang sudah jadi) atau run (untuk perintah shell langsung).

Membuat Workflow Pertama Anda

Mari kita buat workflow nyata dari awal untuk sebuah proyek Python sederhana.

Langkah 1: Buat struktur direktori

# Membuat folder proyek baru
mkdir proyek-python

# Masuk ke folder proyek
cd proyek-python

# Inisialisasi repository Git
git init

# Membuat folder workflow untuk GitHub Actions
mkdir -p .github/workflows

# Output yang diharapkan:
# > Initialized empty Git repository in ./proyek-python/.git/
# > Folder .github/workflows berhasil dibuat

Langkah 2: Buat file Python sederhana

# calculator.py

def tambah(a, b):
    return a + b

def kurang(a, b):
    return a - b

def kali(a, b):
    return a * b

def bagi(a, b):
    # Cek agar tidak membagi dengan nol
    if b == 0:
        raise ValueError("Tidak bisa membagi dengan nol!")
    return a / b

if __name__ == "__main__":
    print("Hasil tambah:", tambah(10, 5))
    print("Hasil kurang:", kurang(10, 5))
    print("Hasil kali:", kali(10, 5))
    print("Hasil bagi:", bagi(10, 5))

# Output yang diharapkan:
# > Hasil tambah: 15
# > Hasil kurang: 5
# > Hasil kali: 50
# > Hasil bagi: 2.0

Langkah 3: Buat file test

# test_calculator.py
import pytest
from calculator import tambah, kurang, kali, bagi

def test_tambah():
    assert tambah(2, 3) == 5
    assert tambah(-1, 1) == 0

def test_kurang():
    assert kurang(5, 3) == 2

def test_kali():
    assert kali(4, 3) == 12

def test_bagi():
    assert bagi(10, 2) == 5.0

    # pytest akan memastikan error ValueError benar-benar muncul
    with pytest.raises(ValueError):
        bagi(10, 0)

# Output yang diharapkan:
# > 4 passed in 0.0Xs
# > Semua pengujian berhasil

Langkah 4: Buat file requirements

# requirements.txt
# Dependensi ini digunakan untuk menjalankan pengujian otomatis di GitHub Actions
pytest==8.1.1

# Output yang diharapkan:
# > Successfully installed pytest-8.1.1
# > Sekarang test dapat dijalankan dengan perintah: pytest

Langkah 5: Buat workflow GitHub Actions

# .github/workflows/python-ci.yml

name: Python CI

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

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        python-version: ['3.10', '3.11', '3.12']  # Uji di 3 versi Python

    steps:
      - name: Checkout repositori
        uses: actions/checkout@v4

      - name: Setup Python ${{ matrix.python-version }}
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}

      - name: Install dependensi
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Jalankan tests dengan pytest
        run: pytest test_calculator.py -v

      - name: Tampilkan coverage (opsional)
        run: |
          pip install pytest-cov
          pytest --cov=calculator test_calculator.py

# Output yang diharapkan:
# > Matrix berjalan 3 kali (Python 3.10, 3.11, 3.12)
# > Semua job selesai dengan status sukses

Setelah kamu push file-file ini ke GitHub, Actions akan otomatis berjalan. Kamu bisa melihat hasilnya di tab Actions di repositori GitHub kamu.

Konsep ini sangat mirip dengan bagaimana kamu perlu memahami struktur dan logika kode — seperti ketika mempelajari OOP di Python: Class, Object, dan Inheritance, kamu butuh memahami bagian-bagian kecil sebelum melihat gambar besar.

Contoh Kasus Nyata

Deploy Otomatis ke Hosting

Berikut contoh workflow yang melakukan deployment otomatis setelah semua test berhasil:

# .github/workflows/deploy.yml

name: Deploy ke Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install
      - run: npm test

  deploy:
    needs: test  # Job ini hanya jalan jika job 'test' berhasil
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy ke server
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}   # Ambil dari GitHub Secrets
          SERVER_HOST: ${{ secrets.SERVER_HOST }}
        run: |
          echo "$SSH_KEY" > private_key
          chmod 600 private_key
          ssh -i private_key user@$SERVER_HOST "cd /app && git pull && npm install && pm2 restart all"

# Output yang diharapkan:
# > Job 'test' selesai sukses
# > Job 'deploy' otomatis berjalan dan aplikasi ter-deploy ke server

Perhatikan penggunaan secrets — ini cara aman menyimpan informasi sensitif seperti password atau API key tanpa menulis langsung di kode. Jika kamu membangun layanan yang butuh keamanan tinggi, seperti platform pembayaran, memahami cara menyimpan secret dengan benar adalah hal krusial.

Konsep penggunaan variabel dan pengelolaan tipe data yang tepat juga penting dalam konteks ini — mirip seperti yang dibahas dalam Tipe Data Dasar di TypeScript untuk memastikan data ditangani dengan benar di setiap lapisan aplikasi.

Troubleshooting: Error yang Sering Muncul

Workflow Tidak Terpicu Setelah Push

Penyebab: Nama branch di konfigurasi on.push.branches tidak cocok dengan branch yang kamu gunakan, atau file workflow berada di lokasi yang salah.

Solusi:

# Pastikan nama branch persis sama (case-sensitive!)
on:
  push:
    branches:
      - main      # bukan 'Main' atau 'MAIN'
      - develop

# Pastikan file ada di path yang benar:
# .github/workflows/nama-file.yml
# (BUKAN .github/workflow/ tanpa 's')

Error: Process completed with exit code 1 pada Step npm test

Penyebab: Ada test yang gagal, atau dependensi tidak terinstall dengan benar karena file package.json atau package-lock.json tidak ada di repositori.

Solusi:

steps:
  - uses: actions/checkout@v4

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

  - name: Install dependensi
    run: npm ci   # Gunakan 'npm ci' bukan 'npm install' untuk CI

  - name: Jalankan test
    run: npm test

# Pastikan package-lock.json ikut di-commit (jangan masuk .gitignore)

Secret Tidak Terbaca, Muncul *** di Log

Penyebab: GitHub sengaja menyembunyikan nilai secret di log untuk keamanan. Masalah umum terjadi ketika nama secret di workflow tidak cocok dengan nama yang disimpan di GitHub Settings.

Solusi:

# Di GitHub: Settings → Secrets and variables → Actions
# Pastikan nama persis sama (case-sensitive)

# Jika secret bernama SSH_PRIVATE_KEY, gunakan:
env:
  SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}  # Bukan secrets.ssh_private_key

# Untuk debug (HATI-HATI, jangan dipakai di produksi):
- name: Cek apakah secret tersedia
  run: |
    if [ -z "$SSH_KEY" ]; then
      echo "Secret KOSONG atau tidak terdefinisi"
    else
      echo "Secret tersedia"
    fi
  env:
    SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}

Pertanyaan yang Sering Diajukan

Apa itu GitHub Actions dan apa bedanya dengan Jenkins?

GitHub Actions adalah platform CI/CD yang terintegrasi langsung di GitHub, sehingga tidak perlu menginstal server terpisah. Jenkins adalah alat CI/CD yang berdiri sendiri dan harus di-self-host, yang artinya kamu perlu mengelola servernya sendiri. Untuk proyek kecil hingga menengah, GitHub Actions jauh lebih mudah digunakan karena langsung tersedia tanpa konfigurasi tambahan.

Berapa biaya menggunakan GitHub Actions?

Untuk repositori publik, GitHub Actions sepenuhnya gratis tanpa batas. Untuk repositori privat, GitHub menyediakan kuota gratis bulanan: 2.000 menit per bulan untuk akun Free, dan 3.000 menit untuk akun Pro. Jika melebihi kuota, kamu akan dikenakan biaya berdasarkan penggunaan.

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

Gunakan fitur GitHub Secrets. Buka repositori kamu → Settings → Secrets and variables → Actions → klik New repository secret. Setelah tersimpan, akses di workflow menggunakan sintaks ${{ secrets.NAMA_SECRET }}. Nilai secret tidak akan pernah ditampilkan dalam log workflow.

Apakah GitHub Actions bisa berjalan berdasarkan jadwal (cron)?

Ya, bisa. Gunakan event schedule dengan sintaks cron:

on:
  schedule:
    - cron: '0 6 * * *'   # Setiap hari jam 06:00 UTC

Ini sangat berguna untuk tugas-tugas seperti backup database, pembersihan cache, atau pengiriman laporan otomatis.

Apa perbedaan uses dan run dalam sebuah step?

uses dipakai untuk menggunakan action yang sudah jadi dari GitHub Marketplace atau repositori lain (misalnya actions/checkout@v4). run dipakai untuk menjalankan perintah shell secara langsung (misalnya npm install atau python test.py). Keduanya bisa digunakan dalam satu workflow sesuai kebutuhan.

Kesimpulan

GitHub Actions adalah alat yang sangat powerful untuk mengotomasi proses pengembangan perangkat lunak. Dengan memahami konsep dasar seperti workflow, job, step, dan event, kamu sudah memiliki fondasi yang kuat untuk membangun pipeline CI/CD yang sesungguhnya.

Kita sudah belajar:

• Konsep dasar CI/CD dan mengapa itu penting
• Komponen utama GitHub Actions beserta fungsinya
• Cara membaca dan menulis file workflow YAML
• Membuat pipeline CI untuk proyek Python dengan testing di berbagai versi
• Contoh deployment otomatis dengan penggunaan secrets yang aman
• Cara mengatasi masalah umum yang sering terjadi

Langkah selanjutnya, coba tambahkan GitHub Actions ke proyek kamu sendiri — mulai dari yang sederhana seperti menjalankan satu perintah test, lalu secara bertahap tambahkan step-step lainnya. Selamat belajar dan terus berlatih! Jika ada pertanyaan atau topik lain yang ingin kamu eksplorasi, KamusNgoding siap menemani perjalanan belajarmu.