GitHub Actions — Automate ทุกอย่างใน CI/CD Pipeline 🤖GitHub Actions — Automate Everything in Your CI/CD Pipeline 🤖

# .github/workflows/hello.yml
name: Hello CI

# ─── Triggers ───
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

# ─── Jobs ───
jobs:
  hello:
    runs-on: ubuntu-latest        # ใช้ Ubuntu runner

    steps:
      - name: Checkout code
        uses: actions/checkout@v4  # ดึง code จาก repo

      - name: Say hello
        run: echo "Hello from GitHub Actions! 🤖"

      - name: Show info
        run: |
          echo "Event: ${{ github.event_name }}"
          echo "Branch: ${{ github.ref_name }}"
          echo "Commit: ${{ github.sha }}"
          echo "Actor: ${{ github.actor }}"

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: 20
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # ─── Job 1: Test ───
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'                    # cache node_modules

      - name: Install dependencies
        run: npm ci                        # clean install (ใช้ lockfile)

      - name: Lint
        run: npm run lint

      - name: Unit Tests
        run: npm test -- --coverage

      - name: Upload coverage
        uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

  # ─── Job 2: Build Docker Image ───
  build:
    needs: test                            # รอ test ผ่านก่อน
    runs-on: ubuntu-latest
    if: github.event_name == 'push'        # build เฉพาะ push (ไม่ build PR)

    permissions:
      contents: read
      packages: write

    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}

    steps:
      - uses: actions/checkout@v4

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Docker metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha,prefix=
            type=ref,event=branch

      - name: Build & Push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha             # GitHub Actions cache
          cache-to: type=gha,mode=max

  # ─── Job 3: Deploy ───
  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'    # deploy เฉพาะ main
    environment: production                 # require approval

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to production
        run: |
          echo "Deploying ${{ needs.build.outputs.image-tag }}"
          # kubectl set image deployment/app app=$IMAGE_TAG
          # หรือ update ArgoCD manifests

on:
  # Push to specific branches
  push:
    branches: [main, develop]
    paths:                               # รันเฉพาะเมื่อไฟล์เหล่านี้เปลี่ยน
      - 'src/**'
      - 'package.json'
    paths-ignore:
      - '**.md'                          # ไม่รันเมื่อแก้ docs

  # Pull Request
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

  # Schedule (cron)
  schedule:
    - cron: '0 2 * * 1'                 # ทุกวันจันทร์ 02:00 UTC

  # Manual trigger (ปุ่มกด)
  workflow_dispatch:
    inputs:
      environment:
        description: 'Deploy environment'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production

  # Tag/Release
  release:
    types: [published]

  # Triggered by another workflow
  workflow_call:                          # reusable workflow

# ตั้ง Secrets ใน GitHub:
# Settings → Secrets and variables → Actions → New repository secret

# ใช้ใน workflow:
jobs:
  deploy:
    steps:
      - name: Deploy
        env:
          API_KEY: ${{ secrets.API_KEY }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: |
          echo "Deploying with secret credentials..."
          # $API_KEY และ $DB_PASSWORD ใช้ได้ใน step นี้
          # ⚠️ GitHub จะ mask secrets ใน logs อัตโนมัติ

      - name: Use GitHub Token
        # GITHUB_TOKEN สร้างให้อัตโนมัติ ไม่ต้องตั้งเอง!
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr list
          gh release create v1.0.0

jobs:
  deploy-staging:
    environment: staging               # ใช้ secrets ของ staging
    steps:
      - run: echo "DB=${{ secrets.DATABASE_URL }}"
        # → ได้ staging DB URL

  deploy-production:
    environment: production            # ใช้ secrets ของ production
    # + สามารถตั้ง required reviewers ได้!
    steps:
      - run: echo "DB=${{ secrets.DATABASE_URL }}"
        # → ได้ production DB URL (คนละค่ากับ staging)

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        node-version: [18, 20, 22]
        # รัน 3 OS × 3 Node = 9 jobs พร้อมกัน!
      fail-fast: false                  # ไม่หยุดถ้า 1 job fail

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

  # Matrix with include/exclude
  test-python:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python: ['3.10', '3.11', '3.12']
        django: ['4.2', '5.0']
        exclude:
          - python: '3.10'
            django: '5.0'              # Django 5 ไม่รองรับ Python 3.10
        include:
          - python: '3.12'
            django: '5.0'
            experimental: true         # เพิ่ม flag พิเศษ

# ❌ ช้า: install ทุกครั้ง (2-3 นาที)
- run: npm ci

# ✅ เร็ว: cache node_modules (10 วินาที)
- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'                        # built-in cache!

# หรือ cache manual
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

# Python
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'

# Docker layer caching
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

# Pin action versions ด้วย SHA (security best practice)
# ❌ ไม่ปลอดภัย
- uses: actions/checkout@v4

# ✅ ปลอดภัยกว่า (pin SHA)
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

# .github/workflows/reusable-deploy.yml
# Workflow ที่ re-use ได้
name: Deploy

on:
  workflow_call:                         # เปิดให้เรียกจาก workflow อื่น
    inputs:
      environment:
        required: true
        type: string
      image-tag:
        required: true
        type: string
    secrets:
      DEPLOY_KEY:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to ${{ inputs.environment }}
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
        run: |
          echo "Deploying ${{ inputs.image-tag }} to ${{ inputs.environment }}"

# .github/workflows/main.yml
# เรียกใช้ reusable workflow
name: Main Pipeline

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  deploy-staging:
    needs: test
    uses: ./.github/workflows/reusable-deploy.yml    # เรียก reusable!
    with:
      environment: staging
      image-tag: ${{ github.sha }}
    secrets:
      DEPLOY_KEY: ${{ secrets.STAGING_DEPLOY_KEY }}

  deploy-production:
    needs: deploy-staging
    uses: ./.github/workflows/reusable-deploy.yml    # เรียกซ้ำ!
    with:
      environment: production
      image-tag: ${{ github.sha }}
    secrets:
      DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}

# .github/workflows/security.yml
name: Security

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'                 # scan ทุกวันจันทร์

jobs:
  # Code scanning (SAST)
  codeql:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@v3

  # Dependency scanning
  dependency-review:
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

  # Container scanning
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:test .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:test
          severity: CRITICAL,HIGH
          exit-code: 1                   # fail ถ้ามี critical/high

  # Secret scanning
  trufflehog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0                 # full history
      - uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

# ติดตั้ง self-hosted runner
# Settings → Actions → Runners → New self-hosted runner
# ทำตาม instructions: download, configure, run

# ใช้ใน workflow
jobs:
  build:
    runs-on: self-hosted                 # ใช้เครื่องตัวเอง!
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  # หรือ label specific
  gpu-test:
    runs-on: [self-hosted, gpu, linux]   # เครื่องที่มี GPU
    steps:
      - run: nvidia-smi                  # check GPU
      - run: python train.py

steps:
  - name: Deploy to staging
    if: github.ref == 'refs/heads/develop'
    run: deploy-staging.sh

  - name: Deploy to production
    if: github.ref == 'refs/heads/main'
    run: deploy-production.sh

  - name: Comment on PR
    if: github.event_name == 'pull_request'
    uses: actions/github-script@v7
    with:
      script: |
        github.rest.issues.createComment({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          body: '✅ Tests passed! Ready to merge.'
        })

  - name: Notify on failure
    if: failure()                         # รันเมื่อ step ก่อนหน้า fail
    run: |
      curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
        -d '{"text":"❌ CI failed on ${{ github.ref }}"}'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

      - name: Upload build
        uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/
          retention-days: 7

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download build
        uses: actions/download-artifact@v4
        with:
          name: build-output
          path: dist/

      - name: Deploy
        run: aws s3 sync dist/ s3://my-bucket/

name: Deploy
concurrency:
  group: deploy-${{ github.ref }}        # 1 deploy per branch
  cancel-in-progress: true               # cancel ตัวเก่า ถ้ามีตัวใหม่

# ป้องกัน: push 3 ครั้งติดกัน → รันแค่ตัวล่าสุด

# README.md — CI badge
![CI](https://github.com/myorg/myapp/actions/workflows/ci.yml/badge.svg)

In the CI/CD Pipeline post we covered the general ideas behind CI/CD. But if you ask which CI/CD tool is the most popular right now? the answer is GitHub Actions — free, built right into GitHub, and no separate server to set up!

Today we go through GitHub Actions in detail, from the basics all the way to production-grade workflows 🤖🐕

---

🤖 What Is GitHub Actions?

GitHub Actions is a CI/CD platform built into GitHub — you write the workflow as YAML and GitHub runs it for you automatically:

GitHub Actions works through a clear sequence of stages, starting the moment a developer pushes code and ending with the final deploy. Each stage plays a different role, and together they let us control the CI/CD process in fine detail and in safety. Here is the whole process at a glance:

The diagram shows that once code is pushed, GitHub Actions starts the process automatically by reading the Workflow file we wrote. Jobs then run on a Runner (a virtual machine) and carry out the Steps we defined. That flow is why we can be confident that every commit is checked and deployed correctly.

Key Concepts

Before writing our first Workflow we need to understand the core concepts of GitHub Actions, because each one has a distinct role and a clear relationship to the others. Understanding them lets us design an efficient CI/CD pipeline — and repair it when something goes wrong:

Concept	What it is	Example
Workflow	The YAML file that defines the automation	.github/workflows/ci.yml
Event	The thing that triggers a workflow	push, pull_request, schedule
Job	A set of steps that run on a single runner	build, test, deploy
Step	One command or one action at a time	run: npm test
Action	Reusable unit of code	actions/checkout@v4
Runner	The machine that runs a job	ubuntu-latest, self-hosted

The table above shows that GitHub Actions has a hierarchical structure: a Workflow is the top level and contains several Jobs, each Job contains several Steps, and each Step can be either an Action or an ordinary command. Once that structure is clear, even a complicated Workflow can be written in an orderly way.

---

📝 Your First Workflow — Hello GitHub Actions

Now that the core concepts are clear, let us write a first Workflow. We start with something simple that prints basic information, which is enough to show how a YAML file is structured and how each event triggers it. This first Workflow is the foundation we will build on as the CI/CD pipeline grows more complex:

# .github/workflows/hello.yml
name: Hello CI

# ─── Triggers ───
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

# ─── Jobs ───
jobs:
  hello:
    runs-on: ubuntu-latest        # use the Ubuntu runner

    steps:
      - name: Checkout code
        uses: actions/checkout@v4  # pull the code from the repo

      - name: Say hello
        run: echo "Hello from GitHub Actions! 🤖"

      - name: Show info
        run: |
          echo "Event: ${{ github.event_name }}"
          echo "Branch: ${{ github.ref_name }}"
          echo "Commit: ${{ github.sha }}"
          echo "Actor: ${{ github.actor }}"

💡 The file must live in .github/workflows/ and nowhere else — GitHub detects it automatically!

The example Workflow above shows several important pieces: declaring triggers through on, naming the runner with runs-on, using Actions from the Marketplace such as actions/checkout, and reading GitHub context variables like ${{ github.actor }}. These are the foundations we will reuse in more complex Workflows — and the other essential is organizing the files into the correct folder.

---

🚀 Real-World CI/CD Pipeline

After that basic Workflow, let us look at a production-grade CI/CD pipeline of the kind used in real work. This pipeline covers everything from testing to building a Docker image to deploying. Each job depends on the ones before it and passes data along, so designing a pipeline like this means thinking about performance, security, and correct handling of secrets.

Node.js — Test + Build + Deploy

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: 20
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # ─── Job 1: Test ───
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'                    # cache node_modules

      - name: Install dependencies
        run: npm ci                        # clean install (uses the lockfile)

      - name: Lint
        run: npm run lint

      - name: Unit Tests
        run: npm test -- --coverage

      - name: Upload coverage
        uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

  # ─── Job 2: Build Docker Image ───
  build:
    needs: test                            # wait for test to pass first
    runs-on: ubuntu-latest
    if: github.event_name == 'push'        # build on push only (never on a PR)

    permissions:
      contents: read
      packages: write

    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}

    steps:
      - uses: actions/checkout@v4

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Docker metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha,prefix=
            type=ref,event=branch

      - name: Build & Push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha             # GitHub Actions cache
          cache-to: type=gha,mode=max

  # ─── Job 3: Deploy ───
  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'    # deploy from main only
    environment: production                 # require approval

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to production
        run: |
          echo "Deploying ${{ needs.build.outputs.image-tag }}"
          # kubectl set image deployment/app app=$IMAGE_TAG
          # or update the ArgoCD manifests

The Workflow above is a production-grade CI/CD pipeline — complex and comprehensive — split into three main jobs: test, build, and deploy. Each job has a clear responsibility, and needs sets the order in which they run. The if conditions let us control which job runs when, and environment gives us an approval gate for the production deployment.

The architecture diagram above makes the flow of work through the CI/CD pipeline plain. The Test Job is the first gatekeeper and must pass before anything else proceeds. The Build Job creates the Docker image and pushes it to the container registry, caching layers along the way for speed. The Deploy Job has an approval gate for safety in production. A design like this catches bugs early and gives us confidence that whatever reaches production has been checked.

---

🎯 Triggers — When Does It Run?

One of the most important parts of GitHub Actions is deciding on the triggers — the events that make a Workflow run. Choosing the right trigger has a large effect on both the performance and the cost of a CI/CD pipeline, because some Workflows need to run on every code change, while others should run only on a schedule or from a manual trigger. Knowing each kind of trigger helps us design automation that fits the shape of the work:

on:
  # Push to specific branches
  push:
    branches: [main, develop]
    paths:                               # run only when these files change
      - 'src/**'
      - 'package.json'
    paths-ignore:
      - '**.md'                          # skip when only the docs change

  # Pull Request
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

  # Schedule (cron)
  schedule:
    - cron: '0 2 * * 1'                 # every Monday at 02:00 UTC

  # Manual trigger (a button)
  workflow_dispatch:
    inputs:
      environment:
        description: 'Deploy environment'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production

  # Tag/Release
  release:
    types: [published]

  # Triggered by another workflow
  workflow_call:                          # reusable workflow

The triggers above show how flexibly GitHub Actions can respond to different events. Using paths and paths-ignore means we do not burn CI time on a documentation-only change. schedule suits nightly builds or security scans, while workflow_dispatch gives us the flexibility of a manual trigger with parameters. Choosing the right triggers reduces the minutes we spend and makes the development workflow smoother.

---

🔐 Secrets & Variables

When we deploy or connect to external services we need credentials and other sensitive data. GitHub Actions has secrets management that lets us store these safely, without hardcoding them into the source. Handling secrets correctly matters enormously for the security of the system, and it also lets us cleanly separate configuration between environments.

# Set Secrets in GitHub:
# Settings → Secrets and variables → Actions → New repository secret

# Use them in a workflow:
jobs:
  deploy:
    steps:
      - name: Deploy
        env:
          API_KEY: ${{ secrets.API_KEY }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: |
          echo "Deploying with secret credentials..."
          # $API_KEY and $DB_PASSWORD are available inside this step
          # ⚠️ GitHub masks secrets in the logs automatically

      - name: Use GitHub Token
        # GITHUB_TOKEN is created for you automatically — you never set it!
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh pr list
          gh release create v1.0.0

The example above shows that GitHub creates GITHUB_TOKEN automatically for every Workflow run, so we can call the GitHub API without minting a token ourselves. Masking secrets in the logs is a very important feature, because it stops sensitive data leaking even when something is echoed or printed by accident. Using secrets this way gives us confidence that credentials sit behind an appropriate level of protection.

Environment Secrets

Beyond repository-level secrets, GitHub also has environment-specific secrets that let us separate configuration between staging and production. Environment secrets matter a great deal, because they let us use different credentials for each environment and also let us set protection rules such as required reviewers or deployment windows:

jobs:
  deploy-staging:
    environment: staging               # uses the staging secrets
    steps:
      - run: echo "DB=${{ secrets.DATABASE_URL }}"
        # → returns the staging DB URL

  deploy-production:
    environment: production            # uses the production secrets
    # + you can require reviewers here!
    steps:
      - run: echo "DB=${{ secrets.DATABASE_URL }}"
        # → returns the production DB URL (a different value from staging)

Environment secrets are a very powerful tool for separating configuration between environments. They help with more than security: they also give us better control over deploys — requiring reviewers for the production environment, say, or limiting the hours in which a deploy may happen, which matters for enterprise environments that need governance and compliance.

---

🔀 Matrix Strategy — Testing Many Versions

One of the recurring challenges in software development is supporting multiple platforms, language versions, or dependencies. Testing every combination by hand takes a very long time and is easy to get wrong. GitHub Actions has a Matrix Strategy that runs many combinations at once, automatically — which not only saves time but also catches compatibility issues sooner:

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        node-version: [18, 20, 22]
        # runs 3 OS × 3 Node = 9 jobs in parallel!
      fail-fast: false                  # do not stop when one job fails

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

  # Matrix with include/exclude
  test-python:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python: ['3.10', '3.11', '3.12']
        django: ['4.2', '5.0']
        exclude:
          - python: '3.10'
            django: '5.0'              # Django 5 does not support Python 3.10
        include:
          - python: '3.12'
            django: '5.0'
            experimental: true         # add an extra flag

Matrix Strategy is one of the most powerful features in GitHub Actions, because it gives us broad coverage of test scenarios. Setting fail-fast: false means we see the result of every combination even when some of them fail. exclude and include let us fine-tune the matrix to what we actually need — which matters, because some combinations have no practical value or are genuinely unsupported. A good matrix balances coverage against efficiency.

---

📦 Caching — 10x Faster!

A common complaint about CI/CD is the waiting, especially the step that downloads and installs dependencies — which sometimes takes longer than the real work. GitHub Actions has a caching mechanism that cuts that time dramatically by keeping already-downloaded dependencies for reuse. Used correctly, caching takes a CI/CD run from minutes down to seconds, and makes the development feedback loop far faster:

# ❌ slow: install every time (2-3 minutes)
- run: npm ci

# ✅ fast: cache node_modules (10 seconds)
- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'                        # built-in cache!

# or cache it manually
- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

# Python
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'

# Docker layer caching
- uses: docker/build-push-action@v5
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

The examples show that caching comes in several forms. The setup actions — setup-node, setup-python and friends — have built-in caching that is trivial to use: naming cache: 'npm' or cache: 'pip' is enough to get the benefit immediately. For Docker, using the GitHub Actions cache (type=gha) means unchanged layers never rebuild, which saves a great deal of time and bandwidth. Understanding and applying caching correctly is one of the quick wins that makes a CI/CD pipeline faster straight away.

---

🧩 Marketplace Actions — Don't Write Your Own!

The GitHub Marketplace holds more than 20,000 ready-made actions — use them, do not write your own:

Rather than spending time writing the same scripts and commands over and over, we can use Actions the community has already built and tested — which saves time and also gives us better reliability and maintainability. Choosing Actions that are widely used and actively maintained reduces the long-term risk. Here are the popular ones worth knowing:

Category	Action	What it does
Checkout	actions/checkout@v4	Pull the code from the repo
Node.js	actions/setup-node@v4	Install Node.js
Python	actions/setup-python@v5	Install Python
Docker	docker/build-push-action@v5	Build + push image
Cache	actions/cache@v4	Cache dependencies
Coverage	codecov/codecov-action@v4	Upload test coverage
Deploy	aws-actions/configure-aws-credentials@v4	AWS authentication
Release	softprops/action-gh-release@v2	Create a GitHub Release
Slack	slackapi/slack-github-action@v1	Send a notification
Security	github/codeql-action@v3	Code scanning (SAST)

# Pin action versions to a SHA (security best practice)
# ❌ not safe
- uses: actions/checkout@v4

# ✅ safer (pinned SHA)
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

The table above lists the most frequently used Actions. Each is specialized and has expert maintainers — actions/setup-node is looked after by GitHub's own team, docker/build-push-action by Docker's. Using them gives us the best practices and optimizations the community has accumulated. What matters, though, is pinning versions to a SHA, to guard against the supply-chain attack that becomes possible if someone modifies an existing Action.

---

♻️ Reusable Workflows — DRY!

Once we have several repositories, or workflows that follow similar patterns, copy-pasting YAML becomes a maintenance problem. Reusable Workflows solve it by letting us build a workflow template that can be called again and again, with flexible parameters and secrets. They give us a single central place to update and improve, instead of editing every repository:

# .github/workflows/reusable-deploy.yml
# A workflow that can be re-used
name: Deploy

on:
  workflow_call:                         # allow other workflows to call this one
    inputs:
      environment:
        required: true
        type: string
      image-tag:
        required: true
        type: string
    secrets:
      DEPLOY_KEY:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to ${{ inputs.environment }}
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}
        run: |
          echo "Deploying ${{ inputs.image-tag }} to ${{ inputs.environment }}"

In the reusable workflow above, workflow_call is what allows another workflow to call this one. Declaring inputs and secrets gives the workflow the flexibility to accept parameters while keeping its security intact. A well-designed reusable workflow should have a clear interface and handle its edge cases, so that it can be relied on.

# .github/workflows/main.yml
# Calling the reusable workflow
name: Main Pipeline

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  deploy-staging:
    needs: test
    uses: ./.github/workflows/reusable-deploy.yml    # call the reusable one!
    with:
      environment: staging
      image-tag: ${{ github.sha }}
    secrets:
      DEPLOY_KEY: ${{ secrets.STAGING_DEPLOY_KEY }}

  deploy-production:
    needs: deploy-staging
    uses: ./.github/workflows/reusable-deploy.yml    # call it again!
    with:
      environment: production
      image-tag: ${{ github.sha }}
    secrets:
      DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}

The example above makes the benefit plain: we call the same workflow for staging and for production, changing only the parameters and the secrets. needs lets us control the order of the deploys, and separating the secrets between environments gives us appropriate access control. Reusable workflows are a good foundation for standardized deployment processes across an entire organization.

---

🔒 Security Scanning

In an era of ever-growing security threats, security scanning in the CI/CD pipeline has become a necessity. GitHub Actions integrates with a wide range of security tools that help us catch vulnerabilities during development — static analysis, dependency scanning, container scanning, secret scanning. Running these checks automatically is how we shift security left, and how we reduce the risk of discovering the problem in production:

# .github/workflows/security.yml
name: Security

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'                 # scan every Monday

jobs:
  # Code scanning (SAST)
  codeql:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript
      - uses: github/codeql-action/analyze@v3

  # Dependency scanning
  dependency-review:
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

  # Container scanning
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:test .
      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:test
          severity: CRITICAL,HIGH
          exit-code: 1                   # fail if anything is critical/high

  # Secret scanning
  trufflehog:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0                 # full history
      - uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

The security scanning workflow above uses a range of tools: CodeQL for static analysis, dependency review to check new dependencies in a PR, Trivy for container scanning, and TruffleHog for secret scanning. Each tool has its own specialty and covers a different set of attack vectors. Putting them together gives comprehensive security coverage and catches a much wider variety of issues.

---

🏠 Self-hosted Runners

When a GitHub-hosted runner is not enough (not fast enough, needs a GPU, needs special network access):

GitHub-hosted runners are convenient and easy to use, but sometimes we need more flexibility — special hardware, access to a private network, or a very specific customized environment. Self-hosted runners give us the freedom to control everything, but they also bring the responsibility of setting up, maintaining and securing that infrastructure ourselves. Choosing between GitHub-hosted and self-hosted means weighing convenience against control:

# Install a self-hosted runner
# Settings → Actions → Runners → New self-hosted runner
# Follow the instructions: download, configure, run

# Use it in the workflow
jobs:
  build:
    runs-on: self-hosted                 # your own machine!
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

  # or target specific labels
  gpu-test:
    runs-on: [self-hosted, gpu, linux]   # a machine that has a GPU
    steps:
      - run: nvidia-smi                  # check GPU
      - run: python train.py

Setting up a self-hosted runner is not hard if you follow GitHub's instructions, but what matters is labelling the runners clearly so that workflows can pick the right machine. Self-hosted runners are what let us do specialized work: ML training that needs a GPU, testing on specific OS versions, or reaching internal services that are not exposed to the public internet.

GitHub-hosted vs Self-hosted

Feature	GitHub-hosted	Self-hosted
Setup	None	You set it up and maintain it
Cost	Free tier (2,000 min/month)	Your own hardware bill
Speed	2-core, 7GB RAM	Whatever you have (64-core if you like!)
Customization	Limited	Full control
Network	Public internet	Private network access
GPU	❌	✅
Best for	General use, open source	Enterprise, ML, heavy builds

The comparison above makes the trade-offs between the two approaches clear. GitHub-hosted suits standard workloads and open source projects that want convenience without infrastructure overhead. Self-hosted suits enterprise environments that need control, performance, or have specific requirements. A mixed approach is entirely possible too — GitHub-hosted for testing, self-hosted for deployment.

---

💡 Advanced Patterns

With the basics of GitHub Actions in hand, let us look at the advanced patterns that help us handle complex scenarios. Conditional logic, artifact management and concurrency control all make workflows more robust and more efficient. These patterns matter most in production workflows that have to cope with a wide range of situations and carry high reliability requirements:

Conditional Steps

steps:
  - name: Deploy to staging
    if: github.ref == 'refs/heads/develop'
    run: deploy-staging.sh

  - name: Deploy to production
    if: github.ref == 'refs/heads/main'
    run: deploy-production.sh

  - name: Comment on PR
    if: github.event_name == 'pull_request'
    uses: actions/github-script@v7
    with:
      script: |
        github.rest.issues.createComment({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          body: '✅ Tests passed! Ready to merge.'
        })

  - name: Notify on failure
    if: failure()                         # runs when an earlier step fails
    run: |
      curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
        -d '{"text":"❌ CI failed on ${{ github.ref }}"}'

Conditional steps are a very common pattern in production workflows, because they let us control behavior by context. Using if with GitHub context variables lets us build smart workflows that respond appropriately to each situation. Using failure() and the other status functions lets us handle error cases efficiently, and integrating with external services such as Slack or the GitHub API gives us rich automation that reacts to whatever happens.

Artifacts — Passing Files Between Jobs

In many cases we need to hand results from one job to another — build artifacts, test results, generated files. GitHub Actions has an artifact system that does this safely and efficiently. Artifacts are not only a way to pass data between jobs; they are also a good way to store build output for debugging or manual verification:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build

      - name: Upload build
        uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/
          retention-days: 7

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download build
        uses: actions/download-artifact@v4
        with:
          name: build-output
          path: dist/

      - name: Deploy
        run: aws s3 sync dist/ s3://my-bucket/

Artifacts are a powerful tool for coordinating between jobs. upload-artifact and download-artifact let us separate the concerns of building and deploying cleanly. Setting retention-days reduces storage use and cost, and naming artifacts meaningfully makes debugging and troubleshooting much easier. Artifacts are also useful for storing test results or logs we want to review later.

Concurrency — Preventing Overlapping Deploys

When several people work in the same team, or workflows are triggered frequently, deploys can end up overlapping — which can cause conflicts or an inconsistent state. Concurrency control handles this by limiting how many workflows may run at once, and by cancelling older runs when a newer one arrives:

name: Deploy
concurrency:
  group: deploy-${{ github.ref }}        # 1 deploy per branch
  cancel-in-progress: true               # cancel the old run when a new one arrives

# prevents: 3 pushes in a row → only the latest one runs

Concurrency control is a very important pattern for production environments. group lets us isolate concurrency by context — by branch, or by environment. cancel-in-progress saves resources and cuts waiting time, but take care where cancelling could cause its own problems, such as a partial deployment. A concurrency strategy has to be designed with the nature of the work, and its consequences, in mind.

---

📋 Best Practices

Writing good GitHub Actions is not only about making them work: it also means thinking about security, performance, maintainability and cost optimization. The practices below are the accumulated experience of the community and the lessons learned in production environments. Following them gives our workflows high reliability and fewer problems in the long run:

1. Pin action versions — use a SHA instead of a tag (@v4 → @sha)
2. Use npm ci, not npm install — it uses the lockfile, it is faster, it is deterministic
3. Cache dependencies — install time drops from 2 minutes → 10 seconds
4. Fail fast — lint first → unit tests → integration → deploy
5. Use environments — separate staging/production secrets + require approvals
6. Limit permissions — permissions: contents: read, no write unless it is genuinely needed
7. Concurrency control — stop deploys from overlapping
8. Reusable workflows — DRY! Do not copy-paste a workflow
9. Timeout — set timeout-minutes: 15 to guard against stuck jobs
10. Status badges — put one in the README so everyone can see the CI status

# README.md — CI badge
![CI](https://github.com/myorg/myapp/actions/workflows/ci.yml/badge.svg)

These best practices are not merely guidelines; they are what production-grade workflows require. Pinning action versions guards against supply-chain attacks. Caching dependencies cuts build time dramatically. Using environments and permissions correctly is a matter of security. And status badges let the team see the state of CI/CD at a glance. Following them gives us confidence in our automation and saves the time we would otherwise lose to fixing problems.

---

💰 Pricing — How Free Is It?

Understanding the GitHub Actions pricing model matters for planning and cost control, especially for organizations with many repositories or workflows that run often. Knowing the limits and the optimization techniques is what lets us use GitHub Actions effectively without going over budget:

Plan	Minutes/month	Storage
Free	2,000 min	500 MB
Team	3,000 min	2 GB
Enterprise	50,000 min	50 GB
Public repos	∞ (unlimited!)	∞

💡 Open source projects get unlimited minutes, free! — another reason open source has settled on GitHub Actions

The pricing table shows that GitHub Actions has a generous free tier, suitable for small teams and personal projects. Giving public repositories unlimited minutes is what lets the open source community use powerful CI/CD without worrying about the bill. For enterprises that need private repositories and heavy usage there are paid plans with more resources. Planning your usage and optimizing your workflows is how you get the most out of the free tier.

---

Summary

GitHub Actions is one of those game-changing tools that made CI/CD far more accessible. Being integrated directly into the GitHub repository makes it much easier to set up and maintain than traditional CI/CD tools, and the rich ecosystem of marketplace actions means we can build sophisticated automation without writing much code. The important thing is to start simple and add complexity only as the requirements grow:

• GitHub Actions = CI/CD built into GitHub — write YAML, it runs automatically
• Workflow = Event → Jobs → Steps — the file lives in .github/workflows/
• Triggers = push, PR, schedule, manual, release, workflow_call
• Secrets = store credentials safely + Environment secrets to separate staging/prod
• Matrix = test many OS × versions at once
• Caching = 10x faster with a dependency cache
• Marketplace = 20,000+ ready-made actions — do not write your own!
• Reusable Workflows = DRY! Call the same workflow again and again
• Security = CodeQL, Trivy, dependency review, secret scanning
• Self-hosted = your own machine, for GPU and heavy builds 🤖🐕