0Pricing
Linux Command Line & Bash Scripting Mastery · Pelajaran

Menjalankan Pengujian Shell dalam Pipeline CI

Hubungkan ShellCheck dan Bats ke GitHub Actions agar setiap perubahan shell hanya lolos jika semua pemeriksaan berhasil.

Menjalankan Pengujian Shell dalam Pipeline CI adalah pelajaran Linux Command Line & Bash Scripting Mastery gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Linux Command Line & Bash Scripting Mastery, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Linux Command Line & Bash Scripting Mastery mencakup 4 pelajaran total.

Mengapa CI Penting untuk Skrip Shell

Skrip shell adalah kode—dan seperti semua kode, skrip tersebut layak mendapatkan gerbang kualitas otomatis. Tanpa CI, kesalahan ketik dalam skrip penerapan dapat diam-diam mencapai produksi dan menyebabkan gangguan pada pukul 3 pagi.

Pipeline CI yang solid untuk proyek Bash menegakkan dua hal pada setiap permintaan pull:

  • Analisis statis melalui ShellCheck—menemukan kesalahan sintaks, pola yang tidak aman, dan masalah portabilitas POSIX sebelum skrip dijalankan.
  • Pengujian unit/integrasi melalui Bats (Sistem Pengujian Otomatis Bash)—menjalankan fungsi Anda dan memastikan perilaku yang benar.

Secara bersama-sama, keduanya membentuk jaring pengaman yang membuat refaktor lebih aman dan proses orientasi lebih cepat. Pelajaran ini menghubungkan kedua alat tersebut ke Actions GitHub, platform CI gratis yang paling umum untuk proyek sumber terbuka dan tim kecil.

Pengantar Actions GitHub untuk Proyek Shell

Actions GitHub adalah CI/CD berbasis peristiwa yang terintegrasi dalam GitHub. Alur kerja adalah file YAML yang disimpan di bawah .github/workflows/. Alur ini dipicu oleh peristiwa (push, pull_request, dan sebagainya) dan menjalankan tugas pada pelaksana yang di-host.

Konsep utama yang perlu Anda ketahui:

  • on:—pemicu (misalnya push, pull_request)
  • jobs:—unit kerja paralel, masing-masing pada VM baru
  • steps:—perintah shell berurutan atau actions yang dapat digunakan ulang dalam suatu tugas
  • runs-on:—citra pelaksana (kita menggunakan ubuntu-latest)

File alur kerja harus di-commit ke repositori. GitHub mendeteksinya secara otomatis—tidak diperlukan penyiapan eksternal.

# Minimal skeleton — .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  shell-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Steps go here"

Memasang ShellCheck dalam Alur Kerja

ShellCheck telah terpasang sebelumnya pada pelaksana ubuntu-latest, jadi biasanya Anda tidak memerlukan langkah pemasangan sama sekali. Namun, versi yang telah terpasang mungkin tertinggal dari rilis terbaru. Untuk build yang dapat direproduksi, tetapkan versi tertentu.

Dua strategi pemasangan:

  • Gunakan biner yang telah terpasang—paling sederhana dan cukup baik untuk sebagian besar proyek.
  • Pasang versi tertentu melalui arsip tar rilis resmi GitHub—menjamin versi pemeriksa lint yang sama secara lokal dan dalam CI.

Langkah di bawah ini menunjukkan pendekatan dengan versi tertentu menggunakan string versi tetap yang disimpan sebagai variabel lingkungan, sehingga pemutakhiran hanya memerlukan perubahan satu baris.

# .github/workflows/ci.yml  — ShellCheck install step
- name: Install ShellCheck
  env:
    SC_VERSION: v0.10.0
  run: |
    curl -sSfL \
      "https://github.com/koalaman/shellcheck/releases/download/${SC_VERSION}/shellcheck-${SC_VERSION}.linux.x86_64.tar.xz" \
      | tar -xJf - --strip-components=1 -C /usr/local/bin shellcheck-${SC_VERSION}/shellcheck
    shellcheck --version

Menjalankan ShellCheck pada Setiap Skrip

Setelah pemasangan, Anda memerlukan langkah yang menemukan dan memeriksa lint semua skrip shell dalam repositori. Gunakan find untuk menemukan file, lalu teruskan file tersebut ke shellcheck.

Opsi penting yang perlu diketahui:

  • -e SC2034—kecualikan aturan tertentu (gunakan secara hemat dan sertakan komentar).
  • --severity=warning—gagal hanya pada peringatan dan tingkat yang lebih tinggi (mengabaikan saran gaya).
  • -x—ikuti direktif source untuk memeriksa lint file yang bersumber juga.

Jika shellcheck menemukan masalah apa pun, program tersebut keluar dengan kode selain nol, yang otomatis menggagalkan langkah CI—tidak diperlukan logika tambahan.

# .github/workflows/ci.yml  — ShellCheck lint step
- name: Lint shell scripts
  run: |
    # Find all .sh files and files with a bash/sh shebang
    mapfile -t scripts < <(
      find . -type f -name '*.sh' -not -path './.git/*'
    )
    if [[ ${#scripts[@]} -eq 0 ]]; then
      echo 'No shell scripts found — skipping.'
      exit 0
    fi
    echo "Linting ${#scripts[@]} file(s)..."
    shellcheck --severity=warning -x "${scripts[@]}"

Apa Itu Bats dan Bagaimana Cara Kerjanya

Bats (Sistem Pengujian Otomatis Bash) adalah kerangka kerja pengujian Bash yang mematuhi TAP. Setiap file pengujian adalah file .bats yang berisi blok @test.

Pengujian lulus jika isi pengujian keluar dengan kode 0 dan gagal jika keluar dengan kode selain nol. Bats menyediakan variabel dan fungsi pembantu:

  • $status—kode keluar dari perintah run terakhir.
  • $output—gabungan stdout+stderr dari perintah run terakhir.
  • $lines—larik baris keluaran.
  • run <cmd>—jalankan perintah tanpa menggagalkan pengujian saat keluar dengan kode selain nol.

Pembantu run sangat penting—tanpanya, perintah yang gagal akan membatalkan pengujian sebelum Anda dapat memeriksa $status.

#!/usr/bin/env bats
# tests/greet.bats

setup() {
  # Runs before every @test block
  source "${BATS_TEST_DIRNAME}/../lib/greet.sh"
}

@test "greet outputs hello with the given name" {
  run greet "Alice"
  [ "$status" -eq 0 ]
  [ "$output" = "Hello, Alice!" ]
}

@test "greet fails when no argument is provided" {
  run greet
  [ "$status" -eq 1 ]
  [[ "$output" == *"Usage"* ]]
}

Memasang Bats-Core melalui Submodul Git

Cara standar untuk menambahkan Bats ke proyek adalah sebagai submodul Git. Cara ini menetapkan commit tertentu, menjaga versi pelaksana tetap sama dengan versi pengembangan lokal, dan menghindari ketergantungan pada pengelola paket.

Jalankan perintah berikut sekali secara lokal, lalu commit hasilnya:

  • git submodule add https://github.com/bats-core/bats-core test/bats
  • git submodule add https://github.com/bats-core/bats-support test/test_helper/bats-support
  • git submodule add https://github.com/bats-core/bats-assert test/test_helper/bats-assert

Dalam CI, pulihkan submodul dengan actions/checkout@v4 dan opsi submodules: recursive. Langkah di bawah ini menunjukkan konfigurasi checkout lengkap.

# .github/workflows/ci.yml  — checkout with submodules
- name: Checkout repository
  uses: actions/checkout@v4
  with:
    submodules: recursive   # restores bats-core + helpers

Menjalankan Pengujian Bats dalam CI

Setelah Bats tersedia (melalui submodul atau pemasangan paket), menjalankan pengujian hanya memerlukan satu perintah. Arahkan perintah ke sebuah direktori, lalu Bats menemukan setiap file .bats secara rekursif dengan opsi --recursive.

Opsi --formatter tap menghasilkan format TAP (Protokol Pengujian Apa Pun), yang dapat diuraikan oleh banyak sistem CI untuk pelaporan pengujian. Pemformat pretty bawaan lebih baik untuk dibaca manusia dalam log mentah.

Gunakan --timing untuk menampilkan pengujian yang lambat sejak awal—pengujian yang memerlukan waktu lebih dari 5 detik biasanya menandakan pemanggilan jaringan yang tidak diinginkan atau tiruan yang tidak tersedia.

# .github/workflows/ci.yml  — Bats test step
- name: Run Bats tests
  run: |
    # If installed as a submodule:
    ./test/bats/bin/bats \
      --recursive \
      --timing \
      tests/

    # If installed via apt or brew (alternative):
    # bats --recursive --timing tests/

Alur Kerja Lengkap: ShellCheck + Bats

Sekarang gabungkan semuanya menjadi satu file alur kerja yang siap digunakan dalam produksi. Praktik terbaik yang diterapkan di sini:

  • Dua tugas terpisah (lint dan test) berjalan secara paralel sehingga umpan balik lebih cepat.
  • Tugas test mendeklarasikan needs: lint agar pengujian hanya berjalan setelah pemeriksaan lint berhasil—menghindari pemborosan menit pelaksana pada kode yang jelas-jelas rusak.
  • Versi actions yang ditetapkan (@v4) mencegah kerusakan tak terduga akibat pemutakhiran dari hulu.
  • Blok permissions: membatasi token alur kerja ke izin minimum yang diperlukan.
# .github/workflows/ci.yml
name: Shell CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  lint:
    name: ShellCheck
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run ShellCheck
        run: |
          mapfile -t scripts < <(find . -name '*.sh' -not -path './.git/*')
          [[ ${#scripts[@]} -gt 0 ]] && shellcheck --severity=warning -x "${scripts[@]}"

  test:
    name: Bats Tests
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - name: Run tests
        run: ./test/bats/bin/bats --recursive --timing tests/

Menyimpan Dependensi dalam Cache untuk Proses yang Lebih Cepat

Saat pembantu Bats atau alat lain dipasang melalui pengelola paket di dalam alur kerja, penggunaan cache sangat mempercepat proses berikutnya. Actions GitHub menyediakan action actions/cache untuk keperluan ini.

Poin penting untuk penggunaan cache yang efektif:

  • Gunakan kunci cache yang mencakup OS, nama alat, dan hash file pengunci—agar cache otomatis tidak berlaku saat dependensi berubah.
  • Fallback restore-keys memungkinkan alur kerja menggunakan cache lama daripada memulai dari awal saat cache tidak ditemukan.
  • Untuk submodul Git, cache jarang diperlukan karena checkout submodul berlangsung cepat. Cache paling bermanfaat untuk pemasangan npm, pip, atau alat terkompilasi.
# .github/workflows/ci.yml  — cache step example
- name: Cache Bats npm helpers
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-bats-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-bats-

- name: Install helpers
  run: npm ci  # uses cache when available

Perlindungan Cabang: Menegakkan Pemeriksaan yang Lulus

Alur kerja CI yang tidak memblokir penggabungan paling-paling hanya bersifat anjuran. Aturan Perlindungan Cabang GitHub mengubah pemeriksaan Anda menjadi gerbang wajib.

Untuk mengonfigurasinya: buka Settings → Branches → Add rule untuk main, lalu aktifkan:

  • Require status checks to pass before merging—pilih ShellCheck dan Bats Tests berdasarkan namanya.
  • Require branches to be up to date before merging—mencegah PR yang lulus pemeriksaan pada basis lama memasukkan kode yang rusak.
  • Do not allow bypassing the above settings—menerapkan aturan bahkan kepada administrator repositori.

Dengan aturan ini, satu-satunya cara untuk melakukan penggabungan adalah melalui PR dengan semua tugas CI berstatus lulus—tepat seperti jaring pengaman yang Anda perlukan.

Men-debug Langkah CI yang Gagal Secara Lokal

Saat proses CI gagal, siklus perbaikan tercepat adalah mereproduksi kegagalan secara lokal sebelum mengirim commit lain. Dua teknik:

  • Jalankan perintah yang sama persis dari langkah yang gagal di terminal Anda—CI menjalankan shell biasa, jadi perintah tersebut dapat disalin dan dijalankan kembali.
  • Gunakan act—alat yang menjalankan alur kerja Actions GitHub secara lokal di dalam Docker, sehingga memberikan kecocokan sedekat mungkin dengan lingkungan pelaksana yang di-host.

Sumber umum kegagalan yang hanya terjadi di CI adalah ketidakcocokan versi alat antara Mac Anda (misalnya find BSD pada macOS dibandingkan dengan find GNU di Ubuntu). Selalu uji dengan opsi --posix atau gunakan act untuk menjalankan citra Ubuntu secara lokal.

#!/usr/bin/env bash
# run_ci_locally.sh  — mimic the CI lint step on your machine
set -euo pipefail

echo '=== ShellCheck ==='
mapfile -t scripts < <(find . -name '*.sh' -not -path './.git/*')
if [[ ${#scripts[@]} -eq 0 ]]; then
  echo 'No .sh files found.'
else
  shellcheck --severity=warning -x "${scripts[@]}"
  echo "Linted ${#scripts[@]} file(s) — OK"
fi

echo '=== Bats ==='
./test/bats/bin/bats --recursive --timing tests/

Pemeriksaan Pengetahuan: Konsep Pipeline CI

Uji pemahaman Anda tentang menghubungkan ShellCheck dan Bats ke Actions GitHub.

Ringkasan: CI Shell dengan ShellCheck dan Bats

Dalam pelajaran ini, Anda membangun pipeline CI lengkap untuk proyek Bash menggunakan Actions GitHub. Berikut hal-hal yang dibahas:

  • Dasar-dasar Actions GitHub—YAML alur kerja berada di .github/workflows/, dipicu oleh push dan pull_request, serta menjalankan tugas pada pelaksana ubuntu-latest.
  • ShellCheck—telah terpasang sebelumnya pada pelaksana Ubuntu; gunakan find untuk menemukan skrip dan --severity=warning -x sebagai gerbang lint praktis.
  • Bats melalui submodul—tetapkan bats-core dan pembantunya sebagai submodul Git; pulihkan semuanya dalam CI dengan submodules: recursive pada action checkout.
  • Pengurutan tugas—gunakan needs: agar pengujian hanya berjalan setelah pemeriksaan lint berhasil, sehingga umpan balik tetap cepat dan komputasi tidak terbuang.
  • Perlindungan cabang—tegakkan pemeriksaan status di pengaturan GitHub agar tidak ada PR yang dapat digabungkan tanpa CI yang seluruhnya lulus.
  • Reproduksi lokal—salin perintah CI langsung ke terminal Anda atau gunakan act untuk men-debug kegagalan tanpa commit tambahan.

Dengan pipeline ini, setiap perubahan shell divalidasi secara otomatis sebelum menyentuh cabang utama Anda.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Menjalankan Pengujian Shell dalam Pipeline CI” gratis?

Ya — teks lengkap “Menjalankan Pengujian Shell dalam Pipeline CI” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Linux Command Line & Bash Scripting Mastery, upgrade ke CoddyKit PRO. Kursus Linux Command Line & Bash Scripting Mastery mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Menjalankan Pengujian Shell dalam Pipeline CI”?

Hubungkan ShellCheck dan Bats ke GitHub Actions agar setiap perubahan shell hanya lolos jika semua pemeriksaan berhasil. Kamu berlatih Linux Command Line & Bash Scripting Mastery dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Linux Command Line & Bash Scripting Mastery?

Tidak diperlukan pengalaman sebelumnya. Linux Command Line & Bash Scripting Mastery di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.

Berapa lama pelajaran “Menjalankan Pengujian Shell dalam Pipeline CI” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Linux Command Line & Bash Scripting Mastery ini?

Ya. Setiap pelajaran Linux Command Line & Bash Scripting Mastery menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. Menguji Fungsi Unit dengan Bats-core
  2. Membuat Mock Perintah dan Stub Alat Eksternal
  3. Fixture, Environment Sementara, dan Cakupan
  4. Menjalankan Pengujian Shell dalam Pipeline CI
← Kembali ke Linux Command Line & Bash Scripting Mastery