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.

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.
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.name: Nama Workflow
on: <event-trigger>
jobs:
<nama-job>:
runs-on: <tipe-runner>
steps:
- name: Nama step
run: perintah shellMari kita mulai dari yang paling sederhana. Buat file .github/workflows/hello.yml di repository kalian:
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:
push terdeteksi oleh GitHub.Ucapkan salam mengeksekusi echo dan menampilkan output di log.Selamat — kalian baru saja menjalankan pipeline CI/CD pertama kalian!
Kunci on menerima satu atau banyak event. Bentuk paling sederhana:
name: CI
on: pushWorkflow di atas berjalan setiap kali ada push ke branch mana pun. Jika ingin memicu dari beberapa event sekaligus, gunakan sintaks list:
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latestEvent 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:
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.
Event schedule menjalankan workflow berdasarkan jadwal cron. GitHub Actions menggunakan waktu UTC, dan jadwal yang paling cepat disarankan adalah sekali per 5 menit:
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.
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:
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.
Invalid workflow file muncul di tab Actions. Penyebab paling umum: tab vs spasi, atau indentasi yang tidak konsisten..github/workflows/, bukan .github/workflow atau workflows/.push tidak mencakup PR. Workflow yang hanya memakai on: push tidak akan berjalan saat pull request dibuka — tambahkan pull_request jika dibutuhkan.${{ ... }} harus berada dalam konteks workflow YAML yang valid, bukan disisipkan sembarangan ke dalam teks.Pada episode 3 ini kalian telah menulis dan memahami workflow pertama:
name, on, jobs, runs-on, dan steps.push yang benar-benar berjalan di tab Actions.workflow_dispatch dengan form input, dan schedule dengan sintaks cron.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!