PricingLoginStart free
Kem Intensif DevOps · Pelajaran

Menjalankan Ujian Shell dalam Saluran Paip CI

Sambungkan ShellCheck dan Bats ke GitHub Actions supaya setiap perubahan shell hanya diterima selepas semua pemeriksaan lulus

Pelajaran 4 daripada 413 langkah

Menjalankan Ujian Shell dalam Saluran Paip CI ialah pelajaran Kem Intensif DevOps percuma di CoddyKit. Ini ialah pelajaran 4 daripada 4. Sebanyak 3 pelajaran dalam laluan pembelajaran ini boleh dibaca sepenuhnya secara percuma — selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan praktikal dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Kem Intensif DevOps, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Kem Intensif DevOps merangkumi sejumlah 4 pelajaran.

Mengapa CI Penting untuk Skrip Cangkerang

Skrip cangkerang ialah kod — dan seperti semua kod, skrip ini wajar mempunyai pengawal kualiti automatik. Tanpa CI, kesilapan taip dalam skrip penerapan boleh sampai ke persekitaran produksi secara senyap dan menyebabkan gangguan pada pukul 3 pagi.

Saluran paip CI yang kukuh untuk projek Bash menguatkuasakan dua perkara pada setiap permintaan tarik:

  • Analisis statik melalui ShellCheck — mengesan ralat sintaks, corak tidak selamat dan isu kebolehlihatan POSIX sebelum skrip dijalankan.
  • Ujian unit/integrasi melalui Bats (Sistem Pengujian Automatik Bash) — melaksanakan fungsi anda dan mengesahkan tingkah laku yang betul.

Secara bersama, kedua-duanya membentuk jaringan keselamatan yang membolehkan pemfaktoran semula dilakukan dengan yakin dan mempercepat proses penyesuaian ahli baharu. Pelajaran ini menghubungkan kedua-dua alat tersebut ke GitHub Actions, iaitu platform CI percuma yang paling lazim untuk projek sumber terbuka dan pasukan kecil.

Pengenalan GitHub Actions untuk Projek Cangkerang

GitHub Actions ialah CI/CD dipacu peristiwa yang terbina dalam GitHub. Aliran kerja ialah fail YAML yang disimpan di bawah .github/workflows/. Aliran ini dicetuskan oleh peristiwa (push, pull_request dan sebagainya) dan menjalankan tugas pada pelancar yang dihoskan.

Konsep utama yang perlu anda ketahui:

  • on: — pencetus (contohnya push, pull_request)
  • jobs: — unit kerja selari, setiap satunya pada VM baharu
  • steps: — perintah cangkerang berjujukan atau tindakan boleh guna semula dalam sesuatu tugas
  • runs-on: — imej pelancar (kami menggunakan ubuntu-latest)

Fail aliran kerja mesti dilakukan commit ke repositori. GitHub mengesannya secara automatik — tiada persediaan luaran diperlukan.

# 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 Aliran Kerja

ShellCheck telah dipasang terlebih dahulu pada pelancar ubuntu-latest, jadi dalam kebanyakan kes anda tidak perlu melakukan sebarang langkah pemasangan. Walau bagaimanapun, versi yang dipasang mungkin ketinggalan daripada keluaran terkini. Untuk binaan yang boleh dihasilkan semula, tetapkan versi tertentu.

Dua strategi pemasangan:

  • Gunakan binari yang telah dipasang — paling mudah dan memadai untuk kebanyakan projek.
  • Pasang versi yang ditetapkan melalui arkib tar keluaran rasmi GitHub — menjamin versi penganalisis yang sama secara setempat dan dalam CI.

Langkah di bawah menunjukkan pendekatan versi ditetapkan menggunakan rentetan versi tetap yang disimpan sebagai pemboleh ubah persekitaran, supaya peningkatan 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

Selepas pemasangan, anda memerlukan langkah yang mencari dan menganalisis semua skrip cangkerang dalam repositori. Gunakan find untuk mencari fail, kemudian salurkan hasilnya kepada shellcheck.

Pilihan penting yang perlu diketahui:

  • -e SC2034 — kecualikan peraturan tertentu (gunakan secara berhemat dan sertakan komen).
  • --severity=warning — gagalkan hanya untuk amaran dan ke atas (abaikan cadangan gaya).
  • -x — ikuti arahan source untuk menganalisis fail yang dipanggil sumber juga.

Jika shellcheck menemui sebarang isu, ia keluar dengan kod bukan sifar, lalu langkah CI gagal secara automatik — tiada logik tambahan diperlukan.

# .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[@]}"

Apakah Bats dan Bagaimanakah Ia Berfungsi

Bats (Sistem Pengujian Automatik Bash) ialah rangka kerja pengujian untuk Bash yang mematuhi TAP. Setiap fail ujian ialah fail .bats yang mengandungi blok @test.

Ujian lulus apabila badannya keluar dengan kod 0 dan gagal apabila keluar dengan kod bukan sifar. Bats menyediakan pemboleh ubah dan fungsi pembantu:

  • $status — kod keluar bagi perintah run yang terakhir.
  • $output — stdout+stderr gabungan daripada perintah run yang terakhir.
  • $lines — tatasusunan baris output.
  • run <cmd> — jalankan perintah tanpa menggagalkan ujian apabila keluar dengan kod bukan sifar.

Pembantu run adalah penting — tanpanya, perintah yang gagal akan menghentikan ujian 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 piawai untuk menambahkan Bats ke dalam projek ialah sebagai submodul Git. Cara ini menetapkan commit tertentu, memastikan versi pelancar sama dengan versi pembangunan setempat dan mengelakkan kebergantungan pada pengurus pakej.

Jalankan perintah ini sekali secara setempat, kemudian lakukan commit terhadap 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 pilihan submodules: recursive. Langkah di bawah menunjukkan konfigurasi daftar keluar yang lengkap.

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

Menjalankan Ujian Bats dalam CI

Setelah Bats tersedia (melalui submodul atau pemasangan pakej), menjalankan ujian hanya memerlukan satu perintah. Halakan perintah kepada direktori dan Bats akan mencari setiap fail .bats secara rekursif dengan pilihan --recursive.

Pilihan --formatter tap menghasilkan format TAP (Protokol Uji Apa Sahaja), yang boleh dihuraikan oleh banyak sistem CI untuk pelaporan ujian. Pemformat pretty lalai lebih sesuai untuk bacaan manusia dalam log mentah.

Gunakan --timing untuk mengesan ujian yang perlahan lebih awal — ujian yang mengambil masa lebih daripada 5 saat biasanya menandakan panggilan rangkaian yang tidak dikehendaki atau mock yang tiada.

# .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/

Aliran Kerja Lengkap: ShellCheck + Bats

Sekarang gabungkan semuanya ke dalam satu fail aliran kerja yang sedia untuk produksi. Amalan terbaik yang digunakan di sini:

  • Dua tugas berasingan (lint dan test) berjalan secara selari untuk memberikan maklum balas yang lebih pantas.
  • Tugas test mengisytiharkan needs: lint supaya ujian hanya dijalankan selepas penganalisisan lulus — ini mengelakkan pembaziran minit pelancar pada kod yang jelas rosak.
  • Versi tindakan yang ditetapkan (@v4) menghalang kerosakan mengejut akibat kemas kini huluan.
  • Blok permissions: mengehadkan token aliran kerja kepada keizinan 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 Kebergantungan dalam Cache untuk Pelaksanaan Lebih Pantas

Apabila pembantu Bats atau alat lain dipasang melalui pengurus pakej dalam aliran kerja, penggunaan cache mempercepat pelaksanaan seterusnya dengan ketara. GitHub Actions menyediakan tindakan actions/cache untuk tujuan ini.

Perkara utama untuk penggunaan cache yang berkesan:

  • Gunakan kunci cache yang merangkumi OS, nama alat dan cincangan fail kunci — supaya cache dibatalkan secara automatik apabila kebergantungan berubah.
  • Sandaran restore-keys membolehkan aliran kerja menggunakan cache lama dan bukannya bermula dari awal apabila cache tidak ditemui.
  • Untuk submodul Git, cache jarang diperlukan kerana daftar keluar submodul adalah pantas. Cache paling berguna untuk npm, pip atau pemasangan alat terkompil.
# .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: Menguatkuasakan Pemeriksaan Berjaya

Aliran kerja CI yang tidak menyekat penggabungan paling baik pun hanya bersifat nasihat. Peraturan Perlindungan Cabang GitHub mengubah pemeriksaan anda menjadi pengawal wajib.

Untuk mengkonfigurasinya: pilih Settings → Branches → Add rule untuk main, kemudian aktifkan:

  • Require status checks to pass before merging — pilih ShellCheck dan Bats Tests mengikut nama.
  • Require branches to be up to date before merging — menghalang PR yang lulus pemeriksaan pada asas lama daripada memasukkan kod yang rosak.
  • Do not allow bypassing the above settings — menguatkuasakan peraturan walaupun terhadap pentadbir repositori.

Dengan peraturan ini, satu-satunya laluan untuk menggabungkan kod ialah PR dengan semua tugas CI yang berjaya — tepatnya jaringan keselamatan yang anda perlukan.

Menyahpepijat Langkah CI yang Gagal Secara Setempat

Apabila pelaksanaan CI gagal, kitaran pembaikan terpantas ialah menghasilkan semula kegagalan itu secara setempat sebelum menghantar commit lain. Dua teknik:

  • Jalankan perintah tepat daripada langkah yang gagal dalam terminal anda — CI menjalankan cangkerang biasa, jadi perintah tersebut boleh disalin dan ditampal untuk dihasilkan semula.
  • Gunakan act — alat yang menjalankan aliran kerja GitHub Actions secara setempat dalam Docker, lalu memberikan padanan yang paling hampir dengan persekitaran pelancar yang dihoskan.

Sumber biasa kegagalan yang hanya berlaku dalam CI ialah ketidakpadanan versi alat antara Mac anda (contohnya find BSD pada macOS berbanding find GNU pada Ubuntu). Sentiasa uji dengan pilihan --posix atau gunakan act untuk menjalankan imej Ubuntu secara setempat.

#!/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/

Semakan Pengetahuan: Konsep Saluran Paip CI

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

Jawab dalam pelajaran interaktif

Ulang Kaji: CI Cangkerang dengan ShellCheck dan Bats

Dalam pelajaran ini, anda membina saluran paip CI lengkap untuk projek Bash menggunakan GitHub Actions. Berikut ialah perkara yang telah anda pelajari:

  • Asas GitHub Actions — YAML aliran kerja berada dalam .github/workflows/, dicetuskan oleh push dan pull_request, serta menjalankan tugas pada pelancar ubuntu-latest.
  • ShellCheck — telah dipasang terlebih dahulu pada pelancar Ubuntu; gunakan find untuk mencari skrip dan --severity=warning -x sebagai pengawal analisis praktikal.
  • Bats melalui submodul — tetapkan bats-core dan pembantu sebagai submodul Git; pulihkannya dalam CI dengan submodules: recursive pada tindakan daftar keluar.
  • Susunan tugas — gunakan needs: supaya ujian hanya dijalankan selepas penganalisisan lulus, sekali gus mengekalkan maklum balas pantas dan mengelakkan pembaziran pengiraan.
  • Perlindungan cabang — kuatkuasakan pemeriksaan status dalam tetapan GitHub supaya tiada PR boleh digabungkan tanpa CI yang berjaya.
  • Penghasilan semula secara setempat — salin perintah CI terus ke terminal anda atau gunakan act untuk menyahpepijat kegagalan tanpa commit tambahan.

Dengan saluran paip ini tersedia, setiap perubahan cangkerang disahkan secara automatik sebelum menyentuh cabang utama anda.

Percuma untuk bermula

Pelajari Kem Intensif DevOps dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus
142
Pelajaran
568
Mula belajar secara percumaLihat kursus penuh

Soalan Lazim

Adakah pelajaran “Menjalankan Ujian Shell dalam Saluran Paip CI” percuma?

Ya — sebanyak 3 pelajaran dalam laluan pembelajaran Kem Intensif DevOps, termasuk “Menjalankan Ujian Shell dalam Saluran Paip CI”, boleh dibaca sepenuhnya secara percuma di web ini. Selepas itu, CoddyKit PRO membuka akses kepada semua pelajaran, serta latihan interaktif dengan penyunting kod terbina dalam dan tutor kecerdasan buatan yang tersedia 24/7. Kursus Kem Intensif DevOps merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Menjalankan Ujian Shell dalam Saluran Paip CI”?

Sambungkan ShellCheck dan Bats ke GitHub Actions supaya setiap perubahan shell hanya diterima selepas semua pemeriksaan lulus Anda berlatih Kem Intensif DevOps menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Kem Intensif DevOps?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Kem Intensif DevOps di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 4 daripada 4.

Berapa lamakah pelajaran “Menjalankan Ujian Shell dalam Saluran Paip CI” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Kem Intensif DevOps ini?

Ya. Setiap pelajaran Kem Intensif DevOps menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

  1. Pengujian Unit Fungsi dengan Bats-core
  2. Meniru Perintah dan Menyediakan Alat Luaran Palsu
  3. Lekapan Ujian, Persekitaran Sementara dan Liputan
  4. Menjalankan Ujian Shell dalam Saluran Paip CI
← Kembali ke Kem Intensif DevOps