Belajar GitHub Actions - Variabel, Contexts, & Environment Variables

#Pendahuluan

Di episode 4 kalian sudah bisa mengisi step dengan run dan uses. Tapi ada satu pertanyaan yang pasti muncul saat workflow kalian mulai nyata: bagaimana cara workflow "tahu" hal-hal tentang konteksnya? — siapa yang mengirim commit, dari branch mana, kode versi apa, atau API mana yang harus dipanggil. Jawabannya ada di tiga mekanisme yang akan kita bedah di episode ini: contexts, environment variables, dan variables.

Memahami ketiganya adalah titik di mana workflow kalian berubah dari "skrip yang dijalankan GitHub" menjadi "program yang cerdas dan dapat dikonfigurasi". Tanpa ini, kalian akan terpaksa menulis nilai yang sama berulang-ulang di dalam file YAML.

#Pembahasan Utama

#Apa itu Contexts?

Context adalah struktur data yang memuat informasi tentang workflow yang sedang berjalan. Setiap context berisi property yang bisa dibaca, dan diakses lewat expression. Context yang paling sering dipakai:

#Mengakses Nilai Context

Nilai context diakses lewat expression yang ditulis di dalam workflow. Selalu dalam konteks fenced code block — expression tidak pernah ditulis sebagai teks bebas:

steps:
  - name: Tampilkan konteks
    run: |
      echo "Di-commit oleh ${{ github.actor }}"
      echo "Commit SHA : ${{ github.sha }}"
      echo "Branch ref : ${{ github.ref }}"

Saat workflow dijalankan, ${{ github.actor }} diganti dengan username yang mengirim event, github.sha diganti dengan hash commit, dan github.ref dengan referensi branch atau tag — misalnya refs/heads/main. Expression seperti ini adalah cara workflow mengambil keputusan: misalnya menjalankan deploy hanya jika github.ref menunjuk ke refs/heads/main.

#Environment Variables: Scope Workflow, Job, dan Step

Environment variables adalah variabel yang nilainya tersedia untuk perintah shell di dalam step. Ada tiga level scope, dan yang paling dekat selalu menang:

• Workflow level — env: di paling atas file, berlaku untuk semua job.
• Job level — env: di dalam job, berlaku untuk semua step job tersebut.
• Step level — env: di dalam satu step, hanya berlaku untuk step itu.

name: Env Scoping
on: push
env:
  WF_LEVEL: dari-workflow
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      JOB_LEVEL: dari-job
    steps:
      - name: Step dengan env sendiri
        env:
          STEP_LEVEL: dari-step
        run: |
          echo "workflow : $WF_LEVEL"
          echo "job      : $JOB_LEVEL"
          echo "step     : $STEP_LEVEL"

Di dalam run, environment variables diakses seperti variabel shell biasa dengan $NAMA — berbeda dengan context yang memakai ${{ ... }}. Perhatikan juga bahwa nilai yang sama bisa diakses lewat context env dalam expression.

#Repository & Environment Variables (vars)

Karena env vars di dalam YAML harus di-commit ke repository, nilainya tidak cocok untuk hal yang berubah antar environment atau yang ingin kalian ubah tanpa edit kode. Untuk itu GitHub menyediakan variables — pasangan nama-nilai yang disimpan di pengaturan repository, bukan di dalam kode.

Cara menyiapkannya: buka repository → Settings → Secrets and variables → Actions → Variables, lalu tambahkan misalnya API_URL dengan nilai https://api.example.com. Di dalam workflow:

steps:
  - name: Panggil API
    run: curl -s "${{ vars.API_URL }}/health"

Kelebihannya: nilai bisa diubah dari UI GitHub tanpa meng-commit perubahan, dan bisa dibedakan per environment. vars cocok untuk hal yang tidak sensitif — untuk yang rahasia, selalu gunakan secrets (dibahas mendalam di episode 9).

#Mengirim Data Antar Step

Ada dua cara resmi mengirim data dari satu step ke step lain:

1. GITHUB_ENV — mengekspor environment variable yang berlaku untuk semua step berikutnya dalam job yang sama.

2. GITHUB_OUTPUT — menulis output yang terikat ke step tertentu, lalu dibaca step lain dengan steps.<id>.outputs.<key>.

Contoh lengkap keduanya:

steps:
  - name: Tentukan versi build
    id: version
    run: |
      echo "app_version=1.4.0" >> "$GITHUB_OUTPUT"
      echo "BUILD_NUMBER=42" >> "$GITHUB_ENV"
  - name: Pakai output step sebelumnya
    run: echo "Versi: ${{ steps.version.outputs.app_version }}"
  - name: Pakai env antar step
    run: echo "Nomor build: $BUILD_NUMBER"

Bedanya: app_version ditulis ke GITHUB_OUTPUT sehingga bisa dibaca step lain (atau job lain) lewat context steps, sedangkan BUILD_NUMBER ditulis ke GITHUB_ENV sehingga tersedia sebagai environment variable biasa bagi semua step berikutnya. Perhatikan juga atribut id: version pada step pertama — id itulah yang menjadi kunci pembacaan output.

#Menggabungkan Semua Mekanisme

Dalam workflow nyata, ketiganya sering bekerja bersama: vars menyimpan URL API, context github menentukan branch, dan GITHUB_ENV membawa nilai antar step:

name: Deploy Staging
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Siapkan info deploy
        run: |
          echo "DEPLOY_URL=${{ vars.API_URL }}" >> "$GITHUB_ENV"
      - name: Tampilkan info
        run: |
          echo "Branch : ${{ github.ref }}"
          echo "Target : $DEPLOY_URL"

Perhatikan kombinasi tiga mekanisme dalam beberapa baris: vars.API_URL dari settings, github.ref dari context, dan DEPLOY_URL dari GITHUB_ENV yang baru saja di-set step sebelumnya.

#Penutup

Pada episode 5 ini kalian telah menguasai sistem nilai dalam workflow:

• Contexts: github, env, vars, job, steps, runner, inputs, dan cara mengakses properti seperti github.actor dan github.sha.
• Environment variables: scope workflow, job, dan step dengan prinsip "yang paling dekat menang".
• Variables (vars): konfigurasi non-sensitif dari repository settings, dapat diubah tanpa commit.
• Berbagi data antar step: GITHUB_ENV untuk env vars lintas step, dan GITHUB_OUTPUT untuk output yang terikat step dan bisa dibaca antar job.

Sekarang workflow kalian sudah bisa berbicara, menyimpan konfigurasi, dan berbagi data antar langkah. Di episode 6 kita akan membahas kontrol eksekusi yang lebih canggih: job dependencies dengan needs dan conditional execution dengan if — bagaimana membuat job berjalan berurutan, hanya berjalan saat kondisi tertentu, dan memanfaatkan status functions seperti success() dan failure(). Sampai jumpa di episode 6!