Belajar GitHub Actions - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kalian sudah memahami konsep CI/CD dan mengapa GitHub Actions menjadi pilihan utama. Sekarang saatnya memahami bagaimana GitHub Actions bekerja dari dalam. Sebelum menulis satu baris YAML pun, ada enam konsep yang harus kalian pegang erat: workflow, event, job, step, action, dan runner. Enam istilah ini adalah bahasa dasar yang akan kalian pakai di semua episode selanjutnya — dari workflow paling sederhana sampai pipeline produksi yang kompleks.

Analogikan GitHub Actions dengan sebuah pabrik otomasi. Di episode ini kita akan membedah pabrik tersebut: apa blue print-nya (workflow), siapa yang menyalakan tombolnya (event), bagaimana pekerjaan dibagi-bagi (job dan step), komponen siap pakai yang dipanggil (action), dan mesin yang menjalankan semuanya (runner).

#Pembahasan Utama

#Enam Komponen Inti

#Workflow

Workflow adalah unit otomasi paling atas — sebuah file YAML yang diletakkan di direktori .github/workflows/ di dalam repository kalian. Nama file bebas (misalnya ci.yml), dan setiap workflow berdiri sendiri, bisa memicu kapan saja, dan bisa dinyalakan atau dimatikan tanpa memengaruhi workflow lain. Dalam satu repository, kalian bisa punya banyak workflow: satu untuk CI, satu untuk deploy, satu lagi untuk scan keamanan.

#Events / Triggers

Event adalah peristiwa yang terjadi di GitHub dan memicu workflow berjalan. Tanpa event, workflow adalah blueprint yang tidak pernah dieksekusi. Contoh event paling umum:

• push — ketika commit di-push ke repository.
• pull_request — ketika PR dibuka, di-update, atau di-merge.
• workflow_dispatch — dijalankan manual lewat tombol atau gh workflow run.
• release, issues, schedule — dan masih banyak lagi, yang akan dibahas rinci di episode 3.

#Jobs

Job adalah kumpulan step yang dieksekusi di runner yang sama dengan environment yang sama. Setiap job berjalan di fresh environment — instalasi sistem operasi yang bersih — dan secara default job-job berjalan paralel satu sama lain. Job adalah unit yang tepat untuk memisahkan tanggung jawab: satu job lint, satu job test, satu job deploy.

#Steps

Step adalah langkah-langkah individual di dalam sebuah job, dieksekusi berurutan dari atas ke bawah dan saling berbagi environment yang sama. Setiap step hanya melakukan satu hal: menjalankan perintah shell lewat run, atau memanggil action lewat uses. Jika sebuah step gagal, step berikutnya tidak akan dijalankan.

#Actions

Action adalah modul reusable terkecil — potongan kode siap pakai yang bisa dipanggil di dalam step dengan sintaks uses. Berbeda dengan run yang mengeksekusi perintah mentah di shell, action adalah unit yang sudah dibungkus: ia menerima input lewat with, menjalankan logikanya, dan menghasilkan output. Action bisa berasal dari GitHub Marketplace (misal actions/checkout@v4), dari repository lain, atau action kustom buatan kalian sendiri.

#Runners

Runner adalah server yang mengeksekusi workflow. Setiap kali sebuah job dijalankan, GitHub menyediakan fresh virtual machine di runner, menginstal system image yang diminta, dan membuangnya setelah job selesai. Kalian tidak perlu memikirkan VM yang satu dengan yang sebelumnya — setiap job selalu dimulai dari lingkungan yang bersih dan identik.

#Anatomi Workflow Lengkap

Mari kita satukan semuanya dalam satu contoh nyata. Perhatikan setiap bagiannya dengan teliti:

name: CI
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout kode
        uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependensi
        run: npm ci
      - name: Jalankan unit test
        run: npm test

Jika workflow ini di-push, apa yang terjadi? Alurnya begini:

1. Event push ke branch main terjadi.
2. GitHub menemukan workflow bernama CI dan mengeksekusi job test.
3. Job test diminta berjalan di runner ubuntu-latest — VM Linux bersih.
4. Empat step dieksekusi berurutan: checkout memakai action untuk mengkloning repository, setup-node menyiapkan Node.js versi 20, lalu dua step run menginstal dependensi dan menjalankan test.

Perhatikan bahwa kode kalian tidak otomatis tersedia di runner — itulah alasan step pertama selalu actions/checkout@v4, yang mengkloning isi repository ke dalam working directory runner.

#GitHub-hosted vs Self-hosted Runner

Runner di GitHub Actions terbagi menjadi dua tipe:

Label standar untuk GitHub-hosted runner antara lain ubuntu-latest, windows-latest, macos-latest, dan ubuntu-24.04-arm untuk arsitektur ARM64. Self-hosted runner, di sisi lain, diregistrasikan ke repository atau organization lewat token, lalu dipanggil dengan label kustom yang kalian definisikan sendiri — misalnya runs-on: [self-hosted, gpu].

#Hubungan Antar Komponen

Mari kita rangkum hierarkinya dari yang paling besar ke paling kecil:

Workflow  (file YAML)
  ├─ dipicu oleh Event (push, pull_request, ...)
  └─ berisi 1..n Job
        └─ tiap Job berjalan di 1 Runner
              └─ berisi 1..n Step (berurutan)
                    └─ tiap Step: run <shell> ATAU uses <action>

Pahamilah pola ini: event memicu workflow → workflow punya job → job berjalan di runner → job berisi step → step menjalankan shell atau memanggil action. Semua episode berikutnya tinggal memperkaya lapisan-lapisan ini.

#Penutup

Pada episode 2 ini kalian telah menguasai arsitektur inti GitHub Actions:

• Enam komponen utama: workflow sebagai file YAML, event sebagai pemicu, job sebagai grup step di satu runner, step sebagai langkah individual, action sebagai modul reusable, dan runner sebagai server eksekusi.
• Anatomi workflow lengkap: dari name dan on, sampai jobs, runs-on, dan steps dengan kombinasi uses serta run.
• Dua tipe runner: GitHub-hosted yang selalu fresh dan mudah dipakai, versus self-hosted yang fleksibel tapi penuh tanggung jawab.

Arsitektur sudah dipahami, sekarang saatnya praktik. Di episode 3 kalian akan menulis workflow pertama — workflow hello world yang benar-benar berjalan — sekaligus mendalami semua jenis event trigger dan filtering event yang membuat workflow kalian hanya berjalan saat dibutuhkan. Sampai jumpa di episode 3!