Belajar GitHub Actions - Menulis Workflow Pertama & Memahami Event Triggers
Episode 3 of 21

Belajar GitHub Actions - Menulis Workflow Pertama & Memahami Event Triggers

Menulis workflow YAML pertama dengan struktur name, on, jobs, runs-on, dan steps, lalu menguasai berbagai event trigger seperti push, workflow_dispatch dengan form input, schedule cron, beserta filtering event.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Di episode 2 kalian sudah memahami arsitektur: workflow, event, job, step, action, dan runner. Sekarang tiba saatnya menulis workflow yang benar-benar berjalan — bukan sekadar teori. Episode ini adalah momen paling seru dalam series: kalian akan membuat workflow pertama, mengirimnya ke GitHub, dan menyaksikan pipeline hidup di tab Actions.

Selain menulis workflow, kita akan membedah salah satu bagian paling penting sekaligus paling membingungkan untuk pemula: event triggers. Apa bedanya push dan pull_request, bagaimana membuat workflow yang bisa dijalankan manual dengan form input, bagaimana menjadwalkan build setiap malam, dan bagaimana membatasi workflow agar hanya berjalan di branch, path, atau tag tertentu.

Pembahasan Utama

Struktur Dasar Workflow

Setiap workflow dibangun dari empat bagian utama:

  • name — nama yang tampil di tab Actions (opsional tapi disarankan).
  • on — daftar event yang memicu workflow.
  • jobs — kumpulan job yang akan dijalankan.
  • runs-on dan steps — di dalam tiap job: runner yang dipakai dan langkah-langkahnya.
Struktur skeleton workflow
name: Nama Workflow
on: <event-trigger>
jobs:
  <nama-job>:
    runs-on: <tipe-runner>
    steps:
      - name: Nama step
        run: perintah shell

Workflow Hello World Pertama

Mari kita mulai dari yang paling sederhana. Buat file .github/workflows/hello.yml di repository kalian:

Workflow hello world pertama
name: Hello World
on: push
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Ucapkan salam
        run: echo "Halo dari GitHub Actions!"

Setelah file di-push ke branch main, buka tab Actions di repository — kalian akan melihat workflow Hello World tereksekusi dan job greet berjalan di runner ubuntu-latest. Langkah-langkahnya:

  1. Event push terdeteksi oleh GitHub.
  2. Runner menyiapkan VM Ubuntu bersih.
  3. Step Ucapkan salam mengeksekusi echo dan menampilkan output di log.

Selamat — kalian baru saja menjalankan pipeline CI/CD pertama kalian!

Memahami Event Triggers

Kunci on menerima satu atau banyak event. Bentuk paling sederhana:

Single event
name: CI
on: push

Workflow di atas berjalan setiap kali ada push ke branch mana pun. Jika ingin memicu dari beberapa event sekaligus, gunakan sintaks list:

Multiple event dengan sintaks list
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest

Manual Trigger: workflow_dispatch

Event workflow_dispatch memungkinkan workflow dijalankan secara manual — lewat tombol di tab Actions, atau perintah gh workflow run. Yang lebih hebat, kalian bisa menambahkan form input interaktif yang muncul saat workflow dijalankan manual:

Workflow manual dengan form input
name: Deploy Manual
on:
  workflow_dispatch:
    inputs:
      environment:
        description: Target lingkungan deploy
        required: true
        default: staging
        type: choice
        options:
          - staging
          - production
      dry-run:
        description: Jalankan tanpa deploy sungguhan
        required: false
        default: false
        type: boolean
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Info deploy
        run: echo "Deploy ke ${{ inputs.environment }}"

Saat kalian menekan tombol Run workflow di tab Actions, GitHub menampilkan form dropdown environment dan checkbox dry-run sesuai definisi di atas. Nilai yang dipilih bisa diakses lewat context inputs — perhatikan bagaimana expression ${{ inputs.environment }} digunakan di dalam step. Coba juga dari terminal: gh workflow run deploy.yml -f environment=production untuk memicu tanpa browser.

Scheduled Trigger: schedule dengan Cron

Event schedule menjalankan workflow berdasarkan jadwal cron. GitHub Actions menggunakan waktu UTC, dan jadwal yang paling cepat disarankan adalah sekali per 5 menit:

Scheduled workflow dengan cron
name: Nightly Build
on:
  schedule:
    - cron: "0 2 * * *"
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Job malam hari
        run: echo "Build dijalankan pukul 02.00 UTC setiap hari"

Sintaks cron memiliki lima kolom: menit, jam, hari dalam bulan, bulan, dan hari dalam minggu. "0 2 * * *" berarti setiap hari pukul 02.00 UTC. Ingat: * berarti setiap, jadi jadwal seperti "30 1 * * 1-5" berarti setiap hari kerja (Senin-Jumat) pukul 01.30 UTC.

Note

GitHub tidak menjamin jadwal cron dijalankan tepat menit; ada kemungkinan penundaan beberapa menit saat antrean runner sedang penuh. Jangan membuat workflow yang sangat bergantung pada presisi detik atau menit.

Filtering Event

Tanpa filter, workflow akan berjalan di semua push — termasuk perubahan dokumentasi dan push ke branch eksperimen. Filtering membuat workflow lebih efisien dan hemat kuota. Ada tiga filter utama:

Filter event: branches, tags, dan paths
name: CI
on:
  push:
    branches:
      - main
      - "feature/*"
    tags:
      - "v*"
    paths:
      - "src/**"
      - "!**.md"

Mari bedah masing-masing:

  • branches — workflow hanya berjalan saat push ke main atau branch yang cocok dengan pola feature/* (wildcard).
  • tags — selain branch, workflow juga dijalankan saat tag dengan pola v* dibuat (misal v1.0.0). Ini berguna untuk workflow rilis.
  • paths — workflow hanya berjalan saat file di dalam src/** berubah, dan diabaikan untuk perubahan **.md (awalan ! menandakan pengecualian). Perfect untuk menghindari rebuild saat cuma edit README.

Filter yang sama juga berlaku untuk event pull_request — contohnya menjalankan test hanya jika kode di direktori frontend berubah. Ada juga varian negatif branches-ignore dan paths-ignore, plus filter types untuk event dengan sub-tipe seperti pull_request yang memungkinkan pemilihan jenis aktivitas PR (opened, synchronize, closed, dan lainnya).

Tip

Kombinasi paling umum di dunia nyata: workflow ci.yml dipicu oleh pull_request dan push ke main dengan filter path paths: ['src/**', '!**.md']. Hasilnya: setiap perubahan kode nyata langsung teruji, sedangkan edit dokumentasi tidak membuang menit runner.

Kesalahan Umum Workflow Pertama

  1. File YAML tidak valid. Error Invalid workflow file muncul di tab Actions. Penyebab paling umum: tab vs spasi, atau indentasi yang tidak konsisten.
  2. Workflow tidak terdeteksi. Pastikan file berada persis di .github/workflows/, bukan .github/workflow atau workflows/.
  3. Lupa bahwa event push tidak mencakup PR. Workflow yang hanya memakai on: push tidak akan berjalan saat pull request dibuka — tambahkan pull_request jika dibutuhkan.
  4. Expression di luar code block. Semua penggunaan ${{ ... }} harus berada dalam konteks workflow YAML yang valid, bukan disisipkan sembarangan ke dalam teks.

Penutup

Pada episode 3 ini kalian telah menulis dan memahami workflow pertama:

  • Struktur dasar: name, on, jobs, runs-on, dan steps.
  • Hello world: workflow sederhana dengan event push yang benar-benar berjalan di tab Actions.
  • Event triggers: single event, multiple event dengan list, workflow_dispatch dengan form input, dan schedule dengan sintaks cron.
  • Filtering event: branches, tags, dan paths agar workflow berjalan hanya saat diperlukan.

Workflow kalian sekarang bisa menampilkan pesan, menerima input manual, berjalan terjadwal, dan hanya aktif di tempat yang tepat. Di episode 4 kita akan naik level: membedah langkah-langkah dalam job — bagaimana run mengeksekusi perintah shell (single-line, multi-line, working-directory, default shell) dan bagaimana uses memanfaatkan action dari Marketplace dengan pemilihan versi yang benar. Sampai jumpa di episode 4!

Belajar GitHub Actions - Menulis Workflow Pertama & Memahami Event Triggers | Belajar GitHub Actions