Belajar Semantic Release - Dry Run & Verifikasi

#Pendahuluan

Di episode 8 kita menyesuaikan aturan commit analyzer, di episode 9 kita membangun gerbang lint dan build. Sekarang tibalah momen paling menegangkan: sebelum rilis asli menyentuh registry dan membuat tag, apakah versi yang dihitung sudah benar?

Jawabannya: dry run. Ini gladi resik yang menjalankan seluruh pipeline semantic-release tanpa efek samping — versi dihitung, changelog disusun, tapi tidak ada yang benar-benar dirilis. Episode ini mengajarkan cara menyiapkan dry run, membaca outputnya, dan memvalidasi perilaku branch sebelum release.

#Pembahasan Utama

#Apa yang Dilakukan Dry Run

Dry run mengikuti alur yang sama dengan actual release: mengambil commit sejak tag terakhir, menganalisisnya dengan commit-analyzer, menghitung versi, lalu men-generate release notes. Bedanya, semua tahap yang bersifat side-effect di-skip:

Tidak ada tag git yang dibuat.
Tidak ada package yang di-publish ke npm.
Tidak ada GitHub release.
Tidak ada commit CHANGELOG.md.

Fungsinya satu: memberi gambaran persis apa yang akan terjadi, sehingga kalian bisa mengoreksi sebelum terlambat.

#Dry Run di Local

Jalankan dari root repository:

Dry run di terminal lokal

npx semantic-release --dry-run --no-ci

Bendera --no-ci memberitahu semantic-release bahwa ini berjalan di luar CI. Tanpa bendera itu, alat ini menolak berjalan karena menganggap hanya boleh dijalankan di environment CI.

Contoh output dry run

$ npx semantic-release --dry-run --no-ci
 
[08:47:00] [semantic-release] › ℹ  Running semantic-release version 24.1.0
[08:47:00] [semantic-release] › ✔  Loaded plugin analyzeCommits
[08:47:00] [semantic-release] › ℹ  There are 3 commits on the main branch
                                   since the last release (v1.2.0).
[08:47:00] [semantic-release] › ℹ  Analyzing commit: feat(api): add retry
[08:47:00] [semantic-release] › ℹ  Analyzing commit: fix(auth): refresh token
[08:47:00] [semantic-release] › ✔  The release type for the commit is minor
[08:47:00] [semantic-release] › ℹ  The next release version is 1.3.0
[08:47:00] [semantic-release] › ✔  Generated release notes
[08:47:00] [semantic-release] › ℹ  This run was started in dry-run mode, so
                                   no release will be created.

#Membaca Output Dry Run

Baris di output	Arti
`There are 3 commits ... since the last release`	Jumlah commit yang dianalisis
`Analyzing commit: feat(api): add retry`	Commit yang sedang dievaluasi
`The release type for the commit is minor`	Level perubahan dari commit
`The next release version is 1.3.0`	Versi final yang akan dirilis
`Generated release notes`	Changelog berhasil disusun
`no commits since last release`	Tidak ada yang layak rilis

Dua baris paling penting adalah release type dan next release version. Release type menjelaskan alasannya (minor karena ada feat), next release version menunjukkan angka persisnya (naik dari 1.2.0 ke 1.3.0). Jika yang muncul "no commits since last release", berarti tidak ada rilis baru — dan itu bukan error.

#Verifikasi Changelog

Di bawah baris "Generated release notes", semantic-release menampilkan draft changelog yang akan dipakai GitHub release. Periksa dua hal: apakah hanya commit yang memang layak yang muncul, dan apakah judul versi memakai format tag yang benar. Changelog yang bising biasanya menandakan aturan releaseRules yang terlalu longgar.

#Dry Run di GitHub Actions

Jadikan dry run sebagai status check otomatis di setiap pull request:

Job dry run pada pull request

name: Release Check
on:
  pull_request:
    branches: [main, staging]
jobs:
  dry-run:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - name: Semantic Release Dry Run
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: npx semantic-release --dry-run --no-ci

Dua detail penting: fetch-depth: 0 memastikan seluruh history ikut ter-checkout agar tag dan commit terbaca, dan permissions: contents: read sudah cukup karena dry run tidak menulis apa pun. Reviewer bisa membuka log step "Semantic Release Dry Run" dan membaca versi yang akan keluar.

Tip

Gabungkan dry run dengan commit analyzer yang sudah kalian kustomisasi di episode 8. Setiap kali aturan releaseRules berubah, hasil dry run di PR langsung menunjukkan dampaknya sebelum aturan itu benar-benar dipakai. Ini umpan balik yang tidak bisa diberikan actual release.

#Validasi Perilaku per Branch

Perilaku yang sama harus diverifikasi di kedua branch. Commit feat(api): add retry yang sama menghasilkan versi berbeda tergantung branch:

$ npx semantic-release --dry-run --no-ci
[08:50:12] [semantic-release] › ℹ  The next release version is 1.3.0-rc.1
[08:50:12] [semantic-release] › ℹ  This run was started in dry-run mode

Dari staging muncul 1.3.0-rc.1, dari main muncul 1.3.0. Kalau kalian melihat suffix rc muncul di main atau hilang di staging, berarti konfigurasi branch di release.config.cjs salah dan harus diperbaiki sebelum actual release diaktifkan.

Warning

Dry run tidak menjamin actual release selalu sukses. Hal yang hanya muncul saat rilis asli adalah validasi token publish npm, izin menulis di registry, dan pembuatan GitHub release. Jadi tetap uji satu kali actual release di environment yang aman sebelum mempercayai seluruh pipeline.

#Kesalahan Umum

Kesalahan	Gejala	Solusi
Lupa `--no-ci`	Ditolak berjalan di luar CI	Tambahkan bendera saat dry run lokal
`fetch-depth` tidak diatur	Commit atau tag tidak terbaca	Set `fetch-depth: 0` di checkout
Salah baca "no commits"	Mengira pipeline rusak	Pahami itu berarti tidak ada rilis
Hanya uji satu branch	Perilaku staging dan main beda	Dry run di kedua branch

#Penutup

Pada episode 10 ini kalian telah:

Menjalankan dry run penuh tanpa tag, publish, atau commit changelog.
Membaca output dry run: release type untuk alasannya dan next release version untuk angkanya.
Menyiapkan job dry run di GitHub Actions dengan fetch-depth: 0 dan permissions: contents: read.
Memvalidasi perilaku staging dan main — suffix rc hanya boleh muncul di prerelease.

Di episode 11 kita akan membahas Branch-based Release Conditions — bagaimana menulis kondisi workflow agar rilis hanya terjadi di branch yang tepat. Sampai jumpa di episode 11!