Belajar Jenkins - Variables, Environment & Secret Management

#Pendahuluan

Pipeline di episode 2-4 masih polos: ia mencetak pesan dan bisa dipicu otomatis, tapi belum berinteraksi dengan data nyata — nomor build, nama job, commit yang sedang dibangun, atau rahasia yang dibutuhkan untuk mengakses registry dan server. Di episode 5 ini, pipeline kalian akan "berbicara". Kita akan membahas built-in environment variables, variabel kustom, dan — yang paling penting untuk karir kalian — secret management dengan Jenkins Credentials.

Bagian terakhir ini layak mendapat perhatian ekstra. Kesalahan paling fatal di dunia Jenkins bukan sintaks yang salah, melainkan kredensial yang bocor ke log build. Setelah episode ini, kalian akan tahu persis bagaimana menyimpan, mengambil, dan memakai rahasia tanpa pernah menuliskannya di tempat yang salah.

#Pembahasan Utama

#Built-in Environment Variables

Setiap build secara otomatis mendapat sekumpulan variabel environment dari Jenkins. Ini "kartu identitas" dari build yang sedang berjalan, dan sangat sering dipakai di pipeline nyata:

Cara mengaksesnya di pipeline: lewat objek env, misalnya env.BUILD_NUMBER (di Groovy), atau langsung sebagai variabel shell $BUILD_NUMBER di dalam blok sh. Mari lihat keduanya:

Membaca variabel bawaan Jenkins

pipeline {
    agent any
    stages {
        stage('Info') {
            steps {
                echo "Nomor build: ${env.BUILD_NUMBER}"
                echo "Nama job: ${env.JOB_NAME}"
                echo "Commit: ${env.GIT_COMMIT}"
            }
        }
    }
}

Perhatikan bahwa ekspresi env.BUILD_NUMBER di dalam string hanyalah string interpolation Groovy — nilainya disisipkan ke dalam string sebelum echo dijalankan. Untuk pemakaian di dalam perintah shell, pakai $BUILD_NUMBER yang dikelola oleh shell itu sendiri. Dua mekanisme ini (Groovy interpolation vs shell expansion) sering membingungkan pemula, jadi ingat: di dalam Groovy pakai env, di dalam shell pakai dollar langsung.

#Mendefinisikan Variabel Kustom

Jenkins juga menyediakan blok environment untuk mendefinisikan variabel sendiri. Variabel yang didefinisikan di level pipeline berlaku di seluruh pipeline; mendefinisikan ulang di level stage membuatnya spesifik untuk stage itu:

Variabel environment kustom

pipeline {
    agent any
    environment {
        APP_NAME = 'my-app'
        REGISTRY = 'registry.example.com'
    }
    stages {
        stage('Print') {
            steps {
                echo "Aplikasi: ${env.APP_NAME}"
                echo "Registry: ${env.REGISTRY}"
            }
        }
    }
}

Diakses persis seperti variabel bawaan: env.APP_NAME di Groovy atau $APP_NAME di shell. Gunakan blok ini untuk nilai yang konstan dan tidak sensitif — versi aplikasi, nama project, URL environment. Untuk nilai rahasia, jangan pernah menaruhnya di sini secara plaintext; gunakan Credentials Provider berikut.

#Jenkins Credentials Provider

Credentials Provider adalah penyimpanan kredensial terpusat di Jenkins (Manage Jenkins → Credentials). Ia menyimpan rahasia dalam bentuk terenkripsi dan mengeksposnya ke pipeline hanya lewat ID — jadi Jenkinsfile tidak pernah mengandung nilai rahasia. Jenis kredensial yang paling umum:

Setiap kredensial mendapat credentialsId unik — inilah yang direferensikan dari pipeline. Nilai sebenarnya disimpan terenkripsi di JENKINS_HOME, dan hanya Jenkins yang bisa mendekripsinya saat dibutuhkan.

#Mengambil Credentials dengan withCredentials

Untuk memakai kredensial di pipeline, gunakan wrapper withCredentials. Wrapper ini mengambil kredensial dari store, menyuntikkannya sebagai variabel environment hanya untuk durasi blok, lalu membersihkannya setelah blok selesai — dan Jenkins secara otomatis menyamarkan nilainya jika muncul di log.

withCredentials([string(credentialsId: 'api-key-prod', variable: 'API_KEY')]) {
    sh 'curl -H "Authorization: Bearer $API_KEY" https://api.example.com/v1/data'
}

Mari bedah: string(...) memilih tipe kredensial, credentialsId: 'api-key-prod' menunjuk kredensial di store, dan variable: 'API_KEY' mendefinisikan nama variabel environment. Di dalam blok, perintah shell memakai $API_KEY — nilai asli tidak pernah muncul di Jenkinsfile. Pola yang sama berlaku untuk tipe lain:

withCredentials([usernamePassword(credentialsId: 'registry-login', usernameVariable: 'REG_USER', passwordVariable: 'REG_PASS')]) {
    sh 'docker login -u "$REG_USER" -p "$REG_PASS" registry.example.com'
}

#Waspada: Jangan Pernah Mencetak Secret

Menyimpan rahasia dengan benar hanya setengah perjuangan; paruh lainnya adalah tidak membocorkannya ke log. Aturan yang tidak bisa ditawar:

1. Jangan pernah echo nilai secret ke Console Output — sekalipun hanya untuk "debugging".
2. Jangan pernah menempelkan secret sebagai argumen command line yang terlihat di log (misal curl -u user:pass ... dalam bentuk literal).
3. Jangan pernah mengubah secret menjadi variabel global yang bisa dicetak di stage lain.
4. Saat menjalankan perintah yang memakai secret, gunakan variabel environment ($API_KEY), bukan string literal.

withCredentials([string(credentialsId: 'api-key', variable: 'TOKEN')]) {
    sh 'curl -H "Authorization: $TOKEN" https://api.example.com' 
    echo "Token saya: ${env.TOKEN}"
}

Perhatikan baris terakhir: itu contoh yang salah dan tidak boleh ditiru — baris itu mencetak rahasia ke log. Baris sh sebelumnya aman karena $TOKEN diekspansi oleh shell (nilainya tidak tertulis sebagai literal), dan Jenkins menyamarkan nilainya di log jika bocor. Satu-satunya cara memakai secret yang benar adalah lewat variabel environment di dalam withCredentials.

#Penutup

Pada episode 5 ini kalian telah memahami:

• Variabel bawaan Jenkins — BUILD_NUMBER, JOB_NAME, GIT_COMMIT, WORKSPACE dan lainnya — yang diakses lewat env.BUILD_NUMBER di Groovy atau $BUILD_NUMBER di shell.
• Variabel kustom dengan blok environment { APP_NAME = 'my-app' }.
• Jenkins Credentials Provider: secret text, secret file, username+password, dan SSH private key, semuanya dirujuk dengan credentialsId.
• Pengambilan kredensial secara aman dengan wrapper withCredentials, dan aturan keras untuk tidak pernah mencetak secret ke log.

Inti yang harus kalian bawa: data build hidup di variabel environment, dan rahasia hidup di Credentials — bukan di Jenkinsfile. Di episode 6 kita akan menggabungkan semua yang sudah dipelajari menjadi pipeline yang interaktif dan aman: parameterized pipeline dengan form input, manual approval gate untuk deployment, dan timeout handling — fondasi untuk alur release yang terkontrol. Sampai jumpa di episode 6!