GitHub Actions · Professional CI/CD Course

1. Introduction to CI/CD

Definition: Continuous Integration (CI) means automatically building and testing every code change. Continuous Delivery (CD) means the software is always ready for deployment. Continuous Deployment automatically releases to production.

Real-world scenario: A team of five developers works on the same repository. Without CI/CD, merging becomes painful, tests are skipped, and deployments are manual and error-prone. With GitHub Actions, every pull request runs tests and produces a build artifact. The main branch auto-deploys to staging.

name: Basic CI Example
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'CI pipeline triggered'

Explanation: The workflow runs on every push and pull request. The job uses an Ubuntu runner and executes a simple echo command. In practice, you would replace the echo with your actual build and test commands.

2. What is GitHub Actions

Definition: GitHub Actions is an event-driven automation platform integrated into GitHub. You define workflows as YAML files inside the .github/workflows directory. Key components: workflow (the YAML file), event (trigger like push or schedule), job (a set of steps that run on the same runner), step (either a shell command or a reusable action), action (a reusable unit, often from the Marketplace), runner (the virtual machine or container executing the job).

name: Show components
on: workflow_dispatch
jobs:
  demo:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: List files
        run: ls -la

Line-by-line breakdown: name identifies the workflow. on: workflow_dispatch allows manual trigger from GitHub UI. jobs groups one or more jobs. runs-on defines the runner image. steps are executed sequentially: first, the actions/checkout action clones the repository; second, run executes the Linux command ls -la.

3. Workflow Basics – YAML explained line by line

YAML syntax essentials: Indentation matters. Use spaces, not tabs. Key-value pairs. Lists start with a dash and space. Strings don’t need quotes unless they contain special characters.

name: Detailed YAML Example
on:
  push:
    branches: [ main, develop ]
jobs:
  test:
    runs-on: ubuntu-22.04
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run tests
        run: npm test

Line-by-line explanation:

• name: Detailed YAML Example – Human-readable workflow name.
• on: – defines the trigger. Under push: we specify branches. The array [ main, develop ] means this workflow runs when code is pushed to either branch.
• jobs: – top-level container for jobs.
• test: – custom job ID. It can be any name.
• runs-on: ubuntu-22.04 – pinned runner version for reproducibility.
• steps: – list of tasks.
• - name: Checkout – descriptive name for the step.
• uses: actions/checkout@v4 – uses the official checkout action version 4.
• run: npm test – executes the npm test script in the runner’s shell.

4. Events, Jobs, Steps

Events: GitHub events like push, pull_request, schedule, workflow_dispatch, release. Jobs: Run in parallel by default, but you can use needs to sequence them. Steps: Each step is either a run (shell command) or uses (external action).

on:
  pull_request:
    types: [opened, synchronize]
  schedule:
    - cron: '0 0 * * 0'
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - run: echo 'Linting...'
  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - run: echo 'Testing...'

Explanation: The workflow triggers on pull request open or update, and also every Sunday at midnight (cron). Two jobs: lint and test. needs: lint makes the test job wait for the lint job to finish successfully. This is how you create sequential pipelines.

5. Runners: GitHub-hosted vs self-hosted

GitHub-hosted runners: Managed by GitHub. Available OS: Ubuntu, Windows, macOS. They are ephemeral, automatically updated, and have 2-core CPU, 7 GB RAM, 14 GB SSD. Self-hosted runners: You provision your own machines (on-prem or cloud). Useful for accessing private networks, larger resources, or custom hardware. Register them via GitHub Actions runner application.

jobs:
  hosted:
    runs-on: ubuntu-latest
  self:
    runs-on: self-hosted
    environment: production

6. Secrets & Environment Variables

Secrets: Encrypted variables stored in repository Settings -> Secrets and variables -> Actions. Accessed via ${{ secrets.NAME }}. They are masked in logs. Environment variables: Defined at workflow, job, or step level using env.

env:
  DEPLOY_ENV: staging
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Use secret safely
        run: echo "Deploying to $DEPLOY_ENV using token length ${#API_TOKEN}"
        env:
          API_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Explanation: The workflow-level environment variable DEPLOY_ENV is available to all jobs. The step defines a step-level environment variable API_TOKEN from a secret. The echo command prints only the length of the token, not the token itself – a safe practice.

7. Artifacts & Caching

Artifacts: Files persisted after workflow run finishes. Useful for test reports, build outputs, logs. Caching: Stores dependencies (like npm, pip, Maven) across runs to speed up workflows.

steps:
  - uses: actions/cache@v3
    with:
      path: ~/.npm
      key: npm-${{ hashFiles('package-lock.json') }}
      restore-keys: |
        npm-
  - run: npm ci
  - uses: actions/upload-artifact@v4
    with:
      name: coverage-report
      path: coverage/

Explanation: The cache action stores the ~/.npm folder. The cache key is based on the hash of package-lock.json. If the lockfile changes, the cache is invalidated and a new one is created. restore-keys provides a fallback. After npm ci, the upload-artifact action saves the coverage/ folder for later download.

8. Docker Integration

Build and push Docker images directly from workflows. Use service containers for integration tests (database, cache).

name: Docker Build and Push
on:
  push:
    branches: [ main ]
jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PASS }}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: username/app:latest, username/app:${{ github.sha }}

Command breakdown: docker/login-action authenticates to Docker Hub (or other registry). docker/build-push-action uses Dockerfile in the repository root. context: . uses the current directory as build context. push: true uploads the image. tags assigns two tags: ‘latest’ and a tag based on Git commit SHA.

9. AWS Deployment using GitHub Actions

Deploy to AWS services like S3, EC2, ECS, or Lambda. Use official aws-actions/configure-aws-credentials. Prefer OIDC (OpenID Connect) over long-term access keys for security.

steps:
  - name: Configure AWS credentials via OIDC
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-actions-role
      aws-region: us-east-1
  - name: Sync to S3
    run: aws s3 sync ./build/ s3://my-static-site/ --delete

OIDC advantage: No need to store AWS access keys as secrets. GitHub’s OIDC provider is trusted by AWS. The role must have trust policy allowing the GitHub repository. The aws s3 sync command intelligently uploads changed files and deletes files not present locally (–delete).

10. Advanced Workflows: Matrix & Reusable Workflows

Matrix strategy: Run the same job with multiple combinations of parameters (Node versions, OS, etc.). Reusable workflows: Call a workflow from another workflow to avoid duplication.

strategy:
  matrix:
    node-version: [16, 18, 20]
    os: [ubuntu-latest, windows-latest]
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: ${{ matrix.node-version }}
  - run: npm test

Reusable workflow example: Create .github/workflows/reusable-ci.yml with on: workflow_call, then call it from another workflow using uses: ./.github/workflows/reusable-ci.yml. This reduces duplication across multiple repositories.