Belajar Jenkins - Event Triggers & Automasi Execution

#Pendahuluan

Di episode 3 kita sudah membangun mesin: controller yang sehat, agent-agent yang siap bekerja, dan labels untuk mengarahkan pekerjaan. Tapi sebuah mesin hanya berguna jika ada yang menyalakannya. Pertanyaan di episode 4 adalah: apa yang memicu sebuah pipeline berjalan? Jawabannya adalah triggers — dan memilih trigger yang tepat menentukan seberapa cepat sebuah perubahan kode sampai ke produksi.

Di dunia nyata, ini perbedaan antara tim yang build-nya jalan "kalau ingat" dan tim yang setiap push otomatis memicu pipeline. Episode ini membahas trigger manual (UI/CLI), jadwal cron dengan simbol hash, poll SCM, webhooks dari GitHub dan GitLab, parsing payload dengan Generic Webhook Trigger, serta Multibranch Pipeline dan Organization Folders untuk otomasi per branch dan pull request.

#Pembahasan Utama

#Metode Pemicuan: Manual via UI dan CLI

Cara paling sederhana adalah menekan tombol Build Now di halaman job. Ini berguna untuk uji coba dan job admin. Tapi dalam otomasi, trigger manual dilakukan lewat CLI — misalnya memicu build dari terminal atau dari tool eksternal:

curl -u admin:API_TOKEN -X POST "http://localhost:8080/job/my-app/build"
curl -u admin:API_TOKEN -X POST "http://localhost:8080/job/my-app/buildWithParameters"

Untuk memicu build secara programatik, kalian memerlukan API token (dibuat di profil user) dan, jika CSRF protection aktif, sebuah crumb — Jenkins menolak POST tanpa crumb dari luar UI. Ini mekanisme keamanan bawaan yang sebaiknya tidak pernah dimatikan. Jika hanya ingin menguji, curl bisa dipakai langsung dari terminal.

#Scheduled Build dengan Cron

Jenkins bisa menjadwalkan build seperti cron Linux, tapi dengan satu perbedaan penting: format lima field (menit, jam, hari-bulan, bulan, hari-minggu) dan dukungan simbol hash H.

Jadwal build harian dengan cron

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')
    }
    stages {
        stage('Build') {
            steps {
                echo 'Build terjadwal berjalan'
            }
        }
    }
}

cron('H 2 * * *') berarti satu kali setiap hari, antara pukul 2.00 dan 2.59. Simbol H (hash) membuat Jenkins memilih menit secara deterministik namun tersebar — penting saat banyak job berbagi jadwal yang sama, misalnya semua pipeline backup dijadwalkan H 2 * * *. Tanpa hash, semua job akan menyerbu pada menit yang persis sama — fenomena yang disebut thundering herd. Dengan hash, menit pilihan tersebar otomatis dan beban terdistribusi.

#Poll SCM

Jika kalian tidak bisa (atau belum mau) memasang webhook, poll SCM adalah jalan tengah: Jenkins memeriksa repository secara berkala dan hanya menjalankan build jika ada perubahan.

Polling repository tiap 15 menit

pipeline {
    agent any
    triggers {
        pollSCM('H/15 * * * *')
    }
    stages {
        stage('Build') {
            steps {
                echo 'Di-poll dan ada perubahan, build dijalankan'
            }
        }
    }
}

Polling melakukan fetch ke repository setiap interval — tanpa perubahan, tidak ada build; dengan perubahan, build dijalankan dengan commit terbaru. Ini lebih hemat daripada build terjadwal yang jalan membabi buta, tapi tetap lebih lambat dari webhook dan menambah beban ke server Git. Aturan praktisnya: webhook untuk otomasi yang responsif, pollSCM sebagai fallback, cron untuk pekerjaan berkala yang tidak bergantung commit.

#Automasi Webhooks: GitHub dan GitLab

Webhook adalah cara paling tepat: server Git mengirimkan notifikasi ke Jenkins setiap kali ada event — push, pull request, atau tag. Jenkins tidak perlu menunggu atau menebak.

Langkah dasarnya:

1. Pasang plugin GitHub (untuk GitHub) atau GitLab (untuk GitLab).
2. Konfigurasi server SCM di Manage Jenkins → System dengan kredensial yang sesuai.
3. Di GitHub, buka Settings → Webhooks pada repository, isi Payload URL dengan http://<jenkins>/github-webhook/ (GitLab: /project/<id>), dan pilih event yang diinginkan (push, pull request).
4. Pastikan job memakai branch dari repository tersebut, dan webhook akan memicunya otomatis.

Saat push mendarat di GitHub, GitHub menghubungi Jenkins, Jenkins memverifikasi event, dan pipeline yang bersangkutan langsung berjalan. Tidak ada polling, tidak ada jeda — perubahan di branch utama bisa sampai ke staging dalam hitungan detik.

#Generic Webhook Trigger untuk Payload JSON

Tidak semua sistem SCM punya plugin resmi. Untuk Bitbucket, Gitea, atau tool internal kalian sendiri, gunakan plugin Generic Webhook Trigger. Ia menerima POST HTTP apa saja, lalu mengekstrak nilai dari payload JSON menggunakan JSONPath:

Parsing payload JSON dari webhook generik

triggers {
    GenericTrigger(
        token: 'deploy-webhook',
        genericVariables: [
            [key: 'REF', value: '$.ref'],
            [key: 'BRANCH', value: '$.repository.branch']
        ],
        printContributedVariables: true,
        printPostContent: true
    )
}

Token di sini berfungsi sebagai kunci rahasia: URL pemicunya menjadi http://localhost:8080/generic-webhook-trigger/invoke?token=deploy-webhook. Payload JSON yang masuk di-parse, nilai ref dan nama branch diekstrak ke variabel pipeline yang bisa dipakai di stage berikutnya. Ini tool paling fleksibel karena tidak tergantung pada format event SCM tertentu.

#Multibranch Pipeline dan Organization Folders

Trigger per-branch biasa masih manual: untuk tiap branch, job harus dibuat terpisah. Multibranch Pipeline menghilangkan pekerjaan itu — satu job memindai repository dan otomatis membuat sub-job untuk setiap branch, tag, dan pull request yang ditemukan, selama branch tersebut punya Jenkinsfile.

Keuntungannya langsung terasa:

• Per-branch CI. Setiap push ke branch apapun menjalankan Jenkinsfile branch itu masing-masing — feature branch dites sebelum dimerger.
• Per-PR build. Pull request / merge request dipindai dan dites secara otomatis, dan hasilnya dilaporkan kembali ke PR sebagai status check.
• Penemuan otomatis. Branch baru langsung mendapat pipeline tanpa konfigurasi manual.

Di atasnya ada Organization Folder (untuk GitHub/GitLab/Bitbucket): satu folder yang memindai seluruh organisasi dan membuat Multibranch Pipeline untuk setiap repository yang berisi Jenkinsfile. Kalian bisa mendapatkan CI untuk puluhan repo hanya dengan satu entitas konfigurasi.

#Penutup

Pada episode 4 ini kalian telah memahami:

• Trigger manual via UI dan CLI (REST API dengan token dan crumb).
• Scheduled build dengan cron('H H * * *'), termasuk makna simbol hash untuk mencegah thundering herd.
• Poll SCM pollSCM('H/15 * * * *') sebagai fallback saat webhook tidak tersedia.
• Webhook GitHub dan GitLab untuk pemicuan real-time, serta Generic Webhook Trigger untuk parsing payload JSON dengan JSONPath.
• Multibranch Pipeline dan Organization Folders untuk otomasi per branch, tag, dan pull request dalam skala besar.

Inti yang harus kalian bawa: pilih trigger sesuai sifat pekerjaan — webhook untuk responsivitas, cron untuk jadwal tetap, poll SCM sebagai cadangan, dan Multibranch untuk otomasi per branch. Di episode 5 kita akan masuk ke "isi" dari pipeline: variables, environment, dan secret management — bagaimana pipeline membaca nomor build, nama job, dan commit, serta bagaimana menyimpan dan mengambil rahasia dengan aman menggunakan Credentials dan withCredentials. Sampai jumpa di episode 5!