Running Shell Tests in CI Pipelines
Wire ShellCheck and Bats into GitHub Actions to gate every shell change on green checks.
Why CI Matters for Shell Scripts
Shell scripts are code — and like all code, they deserve automated quality gates. Without CI, a typo in a deploy script can silently reach production and cause an outage at 3 AM.
A solid CI pipeline for Bash projects enforces two things on every pull request:
- Static analysis via
ShellCheck— catches syntax errors, unsafe patterns, and POSIX portability issues before the script ever runs. - Unit/integration tests via
Bats(Bash Automated Testing System) — executes your functions and asserts correct behaviour.
Together they form a safety net that makes refactoring fearless and onboarding faster. This lesson wires both tools into GitHub Actions, the most common free CI platform for open-source and small-team projects.
GitHub Actions Primer for Shell Projects
GitHub Actions is event-driven CI/CD built into GitHub. A workflow is a YAML file stored under .github/workflows/. It triggers on events (push, pull_request, etc.) and runs jobs on hosted runners.
Key concepts you need:
on:— the trigger (e.g.push,pull_request)jobs:— parallel units of work, each on a fresh VMsteps:— sequential shell commands or reusable actions within a jobruns-on:— the runner image (we useubuntu-latest)
Workflow files must be committed to the repository. GitHub detects them automatically — no external setup required.
# 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"All lessons in this course
- Unit Testing Functions with Bats-core
- Mocking Commands and Stubbing External Tools
- Fixtures, Temp Environments, and Coverage
- Running Shell Tests in CI Pipelines