This guide explains the core components of GitHub Actions workflows, jobs, and steps for automating CI/CD pipelines.
Automating your CI/CD pipelines with GitHub Actions starts with understanding its three building blocks: workflows, jobs, and steps. In this guide, we’ll break down each component, show examples, and highlight best practices for scalable, maintainable pipelines.
A workflow is a YAML-defined automation triggered by repository events (such as push, pull_request, or scheduled events). You store workflows in the .github/workflows directory of your repo.
Copy
Ask AI
name: My Awesome App CIon: push: branches: [ main ] pull_request:jobs: unit-testing: name: Unit Testing runs-on: ubuntu-latest steps: - name: Checkout Repository uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 with: node-version: 20 - name: Install Dependencies run: npm ci - name: Run Tests run: npm test
Workflows must reside in .github/workflows; files ending with .yml or .yaml will be automatically detected.
Key workflow fields:
Field
Description
name
Friendly name displayed in the Actions tab
on
Defines trigger events (e.g., push, pull_request)
jobs
A map of jobs to execute sequentially or in parallel
A job is a sequence of steps that run on the same runner. Jobs execute in isolation, so artifacts and environment variables are not shared unless you explicitly pass them.
Copy
Ask AI
jobs: build-and-test: name: Build & Test runs-on: ubuntu-latest steps: # Steps defined here…
runs-on: Specifies the runner environment (GitHub-hosted or self-hosted).
Jobs can run in parallel by default, or you can enforce a sequence using needs.
By default, each job runs in a clean VM/container. Use needs to share artifacts or enforce order.