Linux Command Line & Bash Scripting Mastery · Ders

Kabuk Testlerini CI Pipeline'larında Çalıştırma

Her kabuk değişikliğini başarılı denetimlere bağlamak için ShellCheck ve Bats'i GitHub Actions'a entegre edin.

Kabuk Testlerini CI Pipeline'larında Çalıştırma, CoddyKit'te ücretsiz bir Linux Command Line & Bash Scripting Mastery dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Linux Command Line & Bash Scripting Mastery öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Linux Command Line & Bash Scripting Mastery kursu toplamda 4 dersten oluşur.

Kabuk Betikleri İçin Sürekli Tümleştirme Neden Önemlidir

Kabuk betikleri de koddur ve tüm kodlar gibi otomatik kalite denetimlerini hak eder. Sürekli tümleştirme olmadan dağıtım betiğindeki bir yazım hatası fark edilmeden üretim ortamına ulaşabilir ve sabaha karşı 3'te hizmet kesintisine yol açabilir.

Bash projeleri için sağlam bir sürekli tümleştirme hattı her çekme isteğinde iki şeyi zorunlu kılar:

Statik çözümleme — ShellCheck aracılığıyla; betki çalıştırılmadan önce sözdizimi hatalarını, güvenli olmayan kalıpları ve POSIX taşınabilirliği sorunlarını yakalar.
Birim ve tümleştirme sınamaları — Bats (Bash Automated Testing System) aracılığıyla; işlevlerinizi çalıştırır ve doğru davranışı doğrular.

Birlikte, yeniden düzenlemeyi korkusuzca yapmanızı ve yeni ekip üyelerinin işe daha hızlı başlamasını sağlayan bir güvenlik ağı oluştururlar. Bu derste her iki aracı da açık kaynak ve küçük ekip projelerinde en yaygın ücretsiz sürekli tümleştirme platformu olan GitHub Actions'a bağlayacaksınız.

Kabuk Projeleri İçin GitHub Actions'a Giriş

GitHub Actions, GitHub'a yerleşik, olay güdümlü bir sürekli tümleştirme ve sürekli teslim platformudur. İş akışı, .github/workflows/ altında saklanan bir YAML dosyasıdır. Olaylarla (push, pull_request vb.) tetiklenir ve barındırılan çalıştırıcılarda işleri yürütür.

Bilmeniz gereken temel kavramlar:

on: — tetikleyici (ör. push, pull_request)
jobs: — her biri yeni bir VM üzerinde çalışan paralel iş birimleri
steps: — bir iş içindeki sıralı kabuk komutları veya yeniden kullanılabilir eylemler
runs-on: — çalıştırıcı imajı (ubuntu-latest kullanıyoruz)

İş akışı dosyaları depoya işlenmelidir. GitHub bunları otomatik olarak algılar; harici bir kurulum gerekmez.

# 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"

İş Akışında ShellCheck Kurulumu

ShellCheck, ubuntu-latest çalıştırıcılarına önceden kuruludur; bu nedenle çoğu durumda hiçbir kurulum adımına ihtiyacınız olmaz. Ancak önceden kurulu sürüm, en son sürümün gerisinde kalabilir. Tekrarlanabilir derlemeler için belirli bir sürümü sabitleyin.

İki kurulum stratejisi:

Önceden kurulu ikili dosyayı kullanmak — en basit seçenektir ve çoğu proje için yeterlidir.
Sabitlenmiş bir sürüm kurmak — resmî GitHub sürüm tar arşivi aracılığıyla; yerel ortamda ve sürekli tümleştirmede aynı denetleyici sürümünü kullanacağınızı garanti eder.

Aşağıdaki adım, yükseltmeleri tek satırlık bir değişikliğe dönüştürmek için ortam değişkeninde saklanan sabit bir sürüm dizesini kullanan sabitlenmiş yaklaşımı gösterir.

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

Her Betikte ShellCheck Çalıştırma

Kurulumdan sonra depodaki tüm kabuk betiklerini bulup denetleyen bir adıma ihtiyacınız vardır. Dosyaları bulmak için find kullanın, ardından bunları shellcheck komutuna borulayın.

Bilinmesi gereken önemli seçenekler:

-e SC2034 — belirli bir kuralı dışarıda bırakır (bunu seyrek kullanın ve bir yorum ekleyin).
--severity=warning — yalnızca uyarılar ve daha yüksek önem düzeyleri için başarısız olur (biçem önerilerini yok sayar).
-x — kaynak olarak eklenen dosyaları da denetlemek için source yönergelerini izler.

shellcheck herhangi bir sorun bulursa sıfır olmayan bir çıkış koduyla sonlanır; bu da ek mantık gerektirmeden sürekli tümleştirme adımını otomatik olarak başarısız kılar.

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

Bats Nedir ve Nasıl Çalışır

Bats (Bash Automated Testing System), Bash için TAP uyumlu bir sınama çatısıdır. Her sınama dosyası, @test blokları içeren bir .bats dosyasıdır.

Bir sınama, gövdesi 0 çıkış koduyla sonlandığında başarılı; sıfır olmayan bir çıkış koduyla sonlandığında başarısız olur. Bats, yardımcı değişkenler ve işlevler sağlar:

$status — son run komutunun çıkış kodu.
$output — son run komutunun stdout+stderr birleşimi.
$lines — çıktı satırlarından oluşan dizi.
run <cmd> — sıfır olmayan çıkışta sınamayı başarısız kılmadan bir komut çalıştırır.

run yardımcısı çok önemlidir; aksi hâlde başarısız bir komut, $status değerini inceleyemeden sınamayı sonlandırır.

#!/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"* ]]
}

Git Alt Modülüyle Bats-Core Kurulumu

Bir projeye Bats eklemenin standart yolu, onu bir Git alt modülü olarak eklemektir. Bu yöntem belirli bir işlemi sabitler, çalıştırıcı sürümünü yerel geliştirme ortamındakiyle aynı tutar ve paket yöneticilerine güvenme gereğini ortadan kaldırır.

Bu komutları yerel ortamınızda bir kez çalıştırın, ardından sonucu işleyin:

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

Sürekli tümleştirmede alt modülleri actions/checkout@v4 ve submodules: recursive seçeneğiyle geri yükleyin. Aşağıdaki adım eksiksiz kullanıma alma yapılandırmasını gösterir.

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

Sürekli Tümleştirmede Bats Sınamalarını Çalıştırma

Bats kullanılabilir hâle geldiğinde (alt modül veya paket kurulumu yoluyla), sınamaları çalıştırmak tek bir komuttur. Bir dizini hedef gösterdiğinizde Bats, --recursive seçeneğiyle tüm .bats dosyalarını özyinelemeli olarak bulur.

--formatter tap seçeneği, birçok sürekli tümleştirme sisteminin sınama raporlaması için ayrıştırabildiği TAP (Test Anything Protocol) biçiminde çıktı verir. Varsayılan pretty biçimlendiricisi, ham günlüklerde insanların okuması için daha uygundur.

Yavaş sınamaları erkenden ortaya çıkarmak için --timing kullanın; 5 saniyeden uzun süren bir sınama genellikle istenmeyen bir ağ çağrısına veya eksik bir sahtesine işaret eder.

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

Eksiksiz Bir İş Akışı: ShellCheck + Bats

Şimdi her şeyi üretime hazır tek bir iş akışı dosyasında birleştirin. Burada şu en iyi uygulamalar uygulanmıştır:

İki ayrı iş (lint ve test) paralel çalışarak daha hızlı geri bildirim sağlar.
test işi, sınamaların yalnızca denetim başarılı olduktan sonra çalışması için needs: lint bildirir; bu, açıkça bozuk kod için çalıştırıcı dakikalarının harcanmasını önler.
Sabitlenmiş eylem sürümleri (@v4), üst akış güncellemelerinden kaynaklanan beklenmedik bozulmaları önler.
Bir permissions: bloğu, iş akışı belirtecinin izinlerini gereken en düşük düzeyle sınırlar.

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

Daha Hızlı Çalıştırmalar İçin Bağımlılıkları Önbelleğe Alma

Bats yardımcıları veya diğer araçlar iş akışı içinde bir paket yöneticisi aracılığıyla kurulduğunda, önbelleğe alma sonraki çalıştırmaları büyük ölçüde hızlandırır. GitHub Actions bunun için actions/cache eylemini sağlar.

Etkili önbelleğe alma için önemli noktalar:

İşletim sistemini, araç adını ve kilit dosyası karmasını içeren bir önbellek anahtarı kullanın; böylece bağımlılıklar değiştiğinde önbellek otomatik olarak geçersiz kılınır.
Bir restore-keys geri dönüşü, önbellek bulunamadığında iş akışının sıfırdan başlamak yerine eski bir önbelleği kullanmasını sağlar.
Git alt modülleri için önbelleğe alma genellikle gerekmez; çünkü alt modülleri kullanıma almak hızlıdır. Önbellek en çok npm, pip veya derlenen araçların kurulumlarında değerlidir.

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

Dal Koruması: Başarılı Denetimleri Zorunlu Kılma

Birleştirmeleri engellemeyen bir sürekli tümleştirme iş akışı, en iyi ihtimalle yalnızca tavsiye niteliğindedir. GitHub Dal Koruması kuralları, denetimlerinizi kesin geçiş koşullarına dönüştürür.

Bunları yapılandırmak için main dalında Settings → Branches → Add rule yolunu izleyin, ardından şunları etkinleştirin:

Birleştirmeden önce durum denetimlerinin başarılı olmasını zorunlu kıl — ada göre ShellCheck ve Bats Tests seçeneklerini belirleyin.
Birleştirmeden önce dalların güncel olmasını zorunlu kıl — eski bir temelde denetimleri geçen çekme isteğinin bozuk kodu birleştirmesini önler.
Yukarıdaki ayarların atlanmasına izin verme — kuralları depo yöneticilerine de uygular.

Bu kurallar yerindeyken birleştirmenin tek yolu, tüm sürekli tümleştirme işlerinin başarılı olduğu bir çekme isteğidir; tam olarak istediğiniz güvenlik ağı budur.

Başarısız Sürekli Tümleştirme Adımlarında Yerel Hata Ayıklama

Bir sürekli tümleştirme çalıştırması başarısız olduğunda, en hızlı düzeltme döngüsü yeni bir işlemeden önce hatayı yerel ortamda yeniden oluşturmaktır. İki teknik:

Aynı komutları çalıştırın — başarısız adımdaki komutları uçbiriminizde çalıştırın; sürekli tümleştirme yalın kabuk kullanır, bu nedenle komutları kopyalayıp yapıştırarak yeniden üretebilirsiniz.
act kullanın — GitHub Actions iş akışlarını Docker içinde yerel olarak çalıştıran bir araçtır ve barındırılan çalıştırıcı ortamıyla mümkün olan en yakın eşleşmeyi sağlar.

Yalnızca sürekli tümleştirmede görülen hataların yaygın bir kaynağı, Mac'iniz ile araç sürümü uyumsuzluğudur (ör. macOS üzerindeki BSD find ile Ubuntu'daki GNU find). Her zaman --posix seçenekleriyle sınayın veya Ubuntu imajını yerel olarak çalıştırmak için act kullanın.

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

Bilgi Denetimi: Sürekli Tümleştirme Hattı Kavramları

ShellCheck ve Bats'i GitHub Actions'a bağlama konusundaki anlayışınızı sınayın.

Özet: ShellCheck ve Bats ile Kabuk Sürekli Tümleştirmesi

Bu derste GitHub Actions kullanarak Bash projeleri için eksiksiz bir sürekli tümleştirme hattı oluşturdunuz. Ele aldığınız konular:

GitHub Actions temelleri — iş akışı YAML dosyası .github/workflows/ altında bulunur, push ve pull_request olaylarında tetiklenir ve işleri ubuntu-latest çalıştırıcılarında yürütür.
ShellCheck — Ubuntu çalıştırıcılarına önceden kuruludur; betikleri bulmak için find, uygulanabilir bir denetim geçiş koşulu için de --severity=warning -x kullanın.
Alt modül aracılığıyla Bats — bats-core'u ve yardımcılarını Git alt modülleri olarak sabitleyin; kullanıma alma eyleminde submodules: recursive kullanarak bunları sürekli tümleştirmede geri yükleyin.
İş sıralaması — sınamaların yalnızca denetim başarılı olduktan sonra çalışması için needs: kullanın; böylece hızlı geri bildirim alır ve boşa hesaplama harcamazsınız.
Dal koruması — GitHub ayarlarında durum denetimlerini zorunlu kılın; böylece hiçbir çekme isteği başarılı sürekli tümleştirme olmadan birleştirilemez.
Yerel yeniden oluşturma — sürekli tümleştirme komutlarını doğrudan uçbiriminize kopyalayın veya ek işleme gerek kalmadan hatalarda hata ayıklamak için act kullanın.

Bu hat yerleştirildiğinde, her kabuk değişikliği ana dalınıza ulaşmadan önce otomatik olarak doğrulanır.

Sıkça Sorulan Sorular

“Kabuk Testlerini CI Pipeline'larında Çalıştırma” dersi ücretsiz mi?

Evet — “Kabuk Testlerini CI Pipeline'larında Çalıştırma” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Linux Command Line & Bash Scripting Mastery kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Linux Command Line & Bash Scripting Mastery kursu toplamda 4 dersten oluşur.

“Kabuk Testlerini CI Pipeline'larında Çalıştırma” dersinde ne öğreneceğim?

Her kabuk değişikliğini başarılı denetimlere bağlamak için ShellCheck ve Bats'i GitHub Actions'a entegre edin. Linux Command Line & Bash Scripting Mastery ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Linux Command Line & Bash Scripting Mastery öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Linux Command Line & Bash Scripting Mastery, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Kabuk Testlerini CI Pipeline'larında Çalıştırma” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Linux Command Line & Bash Scripting Mastery dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Linux Command Line & Bash Scripting Mastery dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

Bats-core ile Fonksiyonları Birim Testine Tabi Tutma
Komutları Taklit Etme ve Dış Araçlar için Saplama Oluşturma
Test Düzenekleri, Geçici Ortamlar ve Kapsam
Kabuk Testlerini CI Pipeline'larında Çalıştırma

← Linux Command Line & Bash Scripting Mastery Sayfasına Dön