{"id":78744,"date":"2026-09-26T04:46:35","date_gmt":"2026-09-26T04:46:35","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=78744"},"modified":"2026-09-26T04:46:38","modified_gmt":"2026-09-26T04:46:38","slug":"github-actions-essentials-learn-ci-cd-in-2-hours","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/github-actions-essentials-learn-ci-cd-in-2-hours\/","title":{"rendered":"GitHub Actions Essentials \u2014 Learn CI\/CD in 2 Hours"},"content":{"rendered":"\n
\n

Audience: Beginners, developers, junior DevOps engineers, QA engineers, and students<\/p>\n\n\n\n

Level: Beginner to early-intermediate<\/p>\n\n\n\n

Duration: About 120 minutes<\/p>\n\n\n\n

Format: Learn, modify, run, break, and fix<\/p>\n\n\n\n

Goal: By the end of this tutorial, you should be able to read an unfamiliar GitHub Actions workflow, create a basic CI workflow, use common Actions features safely, and troubleshoot common failures.<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

Table of Contents<\/h1>\n\n\n\n
    \n
  1. How to Use This Tutorial<\/a><\/li>\n\n\n\n
  2. GitHub Actions in 10 Minutes<\/a><\/li>\n\n\n\n
  3. Understanding Workflow YAML<\/a><\/li>\n\n\n\n
  4. Events and Triggers<\/a><\/li>\n\n\n\n
  5. Jobs, Steps, and Runners<\/a><\/li>\n\n\n\n
  6. Using Actions<\/a><\/li>\n\n\n\n
  7. Variables, Contexts, and Expressions<\/a><\/li>\n\n\n\n
  8. Secrets and GITHUB_TOKEN<\/a><\/li>\n\n\n\n
  9. Hands-On Lab: Build Your First CI Pipeline<\/a><\/li>\n\n\n\n
  10. Matrix Builds<\/a><\/li>\n\n\n\n
  11. Caching<\/a><\/li>\n\n\n\n
  12. Artifacts<\/a><\/li>\n\n\n\n
  13. From CI to CD and Environments<\/a><\/li>\n\n\n\n
  14. GitHub Actions Security: 5 Rules<\/a><\/li>\n\n\n\n
  15. Troubleshooting: The 7-Step Method<\/a><\/li>\n\n\n\n
  16. Final Hands-On Challenge<\/a><\/li>\n\n\n\n
  17. GitHub Actions Essential Cheat Sheet<\/a><\/li>\n\n\n\n
  18. 15-Question Knowledge Check<\/a><\/li>\n\n\n\n
  19. What to Learn Next<\/a><\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    1. How to Use This Tutorial<\/h1>\n\n\n\n

    This tutorial is intentionally small enough to complete in about two hours.<\/p>\n\n\n\n

    The objective is not to memorize every GitHub Actions feature. The objective is to build a strong mental model and become productive with the features that appear in most day-to-day CI workflows.<\/p>\n\n\n\n

    You will repeatedly modify one workflow instead of studying many unrelated examples.<\/p>\n\n\n\n

    The learning sequence is:<\/p>\n\n\n

    Understand\n   |\n   v\nWrite\n   |\n   v\nRun\n   |\n   v\nInspect\n   |\n   v\nBreak<\/span>\n   |\n   v\nFix\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
    1.1 Suggested timing<\/h2>\n\n\n\n
    Time<\/th>Module<\/th>Main outcome<\/th><\/tr><\/thead>
    0-10 min<\/td>GitHub Actions mental model<\/td>Understand the platform<\/td><\/tr>
    10-25 min<\/td>Workflow YAML<\/td>Read and write workflow structure<\/td><\/tr>
    25-38 min<\/td>Triggers, jobs, and steps<\/td>Control when and how work runs<\/td><\/tr>
    38-48 min<\/td>Runners and Actions<\/td>Understand where work runs and how Actions are reused<\/td><\/tr>
    48-60 min<\/td>Variables, contexts, expressions, secrets<\/td>Use runtime data safely<\/td><\/tr>
    60-78 min<\/td>Main CI lab<\/td>Build a real CI pipeline<\/td><\/tr>
    78-90 min<\/td>Matrix, cache, artifacts<\/td>Add important CI capabilities<\/td><\/tr>
    90-101 min<\/td>CI to CD<\/td>Understand deployment flow<\/td><\/tr>
    101-110 min<\/td>Security<\/td>Learn the five rules that matter most<\/td><\/tr>
    110-117 min<\/td>Troubleshooting<\/td>Debug failures systematically<\/td><\/tr>
    117-120 min<\/td>Challenge<\/td>Apply what you learned<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    1.2 Prerequisites<\/h2>\n\n\n\n
    You should have:<\/p>\n\n\n\n
      \n
    • a GitHub account;<\/li>\n\n\n\n
    • access to a repository where you can create branches and commits;<\/li>\n\n\n\n
    • basic Git knowledge;<\/li>\n\n\n\n
    • basic command-line knowledge;<\/li>\n\n\n\n
    • optional Node.js knowledge for the hands-on lab.<\/li>\n<\/ul>\n\n\n\n
      You do not need prior GitHub Actions experience.<\/p>\n\n\n\n
      1.3 What this tutorial intentionally does not cover<\/h2>\n\n\n\n
      The following topics are important, but they belong in a longer course:<\/p>\n\n\n\n
        \n
      • custom JavaScript actions;<\/li>\n\n\n\n
      • custom Docker actions;<\/li>\n\n\n\n
      • advanced reusable workflow architecture;<\/li>\n\n\n\n
      • OpenID Connect cloud federation implementation;<\/li>\n\n\n\n
      • Kubernetes deployment;<\/li>\n\n\n\n
      • Terraform and infrastructure-as-code workflows;<\/li>\n\n\n\n
      • Actions Runner Controller;<\/li>\n\n\n\n
      • enterprise governance;<\/li>\n\n\n\n
      • monorepo optimization;<\/li>\n\n\n\n
      • artifact attestations;<\/li>\n\n\n\n
      • advanced release engineering;<\/li>\n\n\n\n
      • organization-wide workflow policy.<\/li>\n<\/ul>\n\n\n\n
        \n\n\n\n
        2. GitHub Actions in 10 Minutes<\/h1>\n\n\n\n
        2.1 What is GitHub Actions?<\/h2>\n\n\n\n
        GitHub Actions is GitHub’s automation platform.<\/p>\n\n\n\n
        It listens for events such as:<\/p>\n\n\n\n
          \n
        • code being pushed;<\/li>\n\n\n\n
        • a pull request being opened;<\/li>\n\n\n\n
        • a pull request being updated;<\/li>\n\n\n\n
        • a release being created;<\/li>\n\n\n\n
        • a user manually starting a workflow;<\/li>\n\n\n\n
        • a schedule being reached.<\/li>\n<\/ul>\n\n\n\n
          When an event matches a workflow definition, GitHub starts a workflow run.<\/p>\n\n\n\n
          The most common use is CI\/CD.<\/p>\n\n\n\n
          Typical CI tasks include:<\/p>\n\n\n\n
            \n
          • checkout source code;<\/li>\n\n\n\n
          • install dependencies;<\/li>\n\n\n\n
          • lint code;<\/li>\n\n\n\n
          • run unit tests;<\/li>\n\n\n\n
          • run integration tests;<\/li>\n\n\n\n
          • compile or build software;<\/li>\n\n\n\n
          • create packages;<\/li>\n\n\n\n
          • upload build artifacts.<\/li>\n<\/ul>\n\n\n\n
            Typical CD tasks include:<\/p>\n\n\n\n
              \n
            • publish a package;<\/li>\n\n\n\n
            • push a container image;<\/li>\n\n\n\n
            • deploy to staging;<\/li>\n\n\n\n
            • deploy to production;<\/li>\n\n\n\n
            • run smoke tests;<\/li>\n\n\n\n
            • roll back a deployment.<\/li>\n<\/ul>\n\n\n\n
              2.2 The core mental model<\/h2>\n\n\n\n
              Remember this sequence:<\/p>\n\n\n
              Event\n  |\n  v\nWorkflow\n  |\n  v\nJob\n  |\n  v\nRunner\n  |\n  v\nSteps\n  |\n  v\nActions \/ Commands\n  |\n  v\nResult\n<\/code><\/span><\/pre>\n\n\n
              That single flow explains most of GitHub Actions.<\/p>\n\n\n\n
              2.3 Core terms<\/h2>\n\n\n\n
              Term<\/th>Simple meaning<\/th><\/tr><\/thead>
              Event<\/td>Something happened in or around GitHub<\/td><\/tr>
              Workflow<\/td>Automation defined in YAML<\/td><\/tr>
              Workflow run<\/td>One execution of a workflow<\/td><\/tr>
              Job<\/td>A unit of work scheduled to a runner<\/td><\/tr>
              Runner<\/td>The machine that executes a job<\/td><\/tr>
              Step<\/td>A task inside a job<\/td><\/tr>
              Action<\/td>Reusable automation executed by a step<\/td><\/tr>
              Command<\/td>A shell command executed by a step<\/td><\/tr>
              Artifact<\/td>A file kept from a workflow run<\/td><\/tr>
              Cache<\/td>Reusable data intended to make future runs faster<\/td><\/tr>
              Secret<\/td>Protected sensitive configuration<\/td><\/tr>
              Variable<\/td>Non-sensitive configuration<\/td><\/tr>
              Context<\/td>Structured runtime information from GitHub<\/td><\/tr>
              Expression<\/td>GitHub’s ${{ }}<\/code> evaluation syntax<\/td><\/tr>
              Environment<\/td>A named deployment target such as staging or production<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              2.4 CI, continuous delivery, and continuous deployment<\/h2>\n\n\n\n
              These terms are related but different.<\/p>\n\n\n\n
              Practice<\/th>Question it answers<\/th>Example<\/th><\/tr><\/thead>
              Continuous Integration<\/td>Is this code safe to merge?<\/td>Build, lint, test<\/td><\/tr>
              Continuous Delivery<\/td>Is this release ready to deploy?<\/td>Build, package, stage, wait for approval<\/td><\/tr>
              Continuous Deployment<\/td>Can validated changes deploy automatically?<\/td>CI plus automatic production deployment<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              A beginner should first learn CI. Deployment should come after you understand workflow execution and security.<\/p>\n\n\n\n
              2.5 Your first workflow<\/h2>\n\n\n\n
              Create this file:<\/p>\n\n\n
              .github\/workflows\/hello.yml\n<\/code><\/span><\/pre>\n\n\n
              Add:<\/p>\n\n\n
              name: Hello GitHub Actions\n\non:\n  push:\n\njobs:\n  hello:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Say hello\n        run: echo<\/span> \"Hello from GitHub Actions\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              Commit and push it.<\/p>\n\n\n\n
              Then open:<\/p>\n\n\n
              Repository -> Actions -> Hello GitHub Actions\n<\/code><\/span><\/pre>\n\n\n
              You should see a workflow run.<\/p>\n\n\n\n
              2.6 What happened?<\/h2>\n\n\n
              You pushed a commit\n      |\n      v\nGitHub detected push\n      |\n      v\nhello.yml matched the event\n      |\n      v\nWorkflow run was created\n      |\n      v\nJob \"hello\"<\/span> was scheduled\n      |\n      v\nUbuntu runner started\n      |\n      v\nStep executed echo<\/span> command\n      |\n      v\nWorkflow completed\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              That is GitHub Actions in its simplest useful form.<\/p>\n\n\n\n
              \n\n\n\n
              3. Understanding Workflow YAML<\/h1>\n\n\n\n
              GitHub Actions workflows are YAML files stored under:<\/p>\n\n\n
              .github\/workflows\/\n<\/code><\/span><\/pre>\n\n\n
              Common filenames:<\/p>\n\n\n
              ci<\/span>.yml<\/span>\npull-request-ci<\/span>.yml<\/span>\nrelease<\/span>.yml<\/span>\ndeploy-production<\/span>.yml<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
              Both .yml<\/code> and .yaml<\/code> work.<\/p>\n\n\n\n
              3.1 YAML indentation matters<\/h2>\n\n\n\n
              Correct:<\/p>\n\n\n
              jobs:\n  test:\n    runs-on: ubuntu-latest\n<\/code><\/span><\/pre>\n\n\n
              Incorrect:<\/p>\n\n\n
              jobs:\ntest:\n  runs-on: ubuntu-latest\n<\/code><\/span><\/pre>\n\n\n
              YAML uses indentation to describe structure.<\/p>\n\n\n\n
              3.2 The basic workflow structure<\/h2>\n\n\n\n
              Study this example carefully:<\/p>\n\n\n
              name: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Checkout code\n        uses: actions\/checkout@v6\n\n      - name: Run a command\n        run: echo<\/span> \"CI is running\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              The important keywords are:<\/p>\n\n\n
              name\non\npermissions\njobs\nruns-on\nsteps\nuses\nrun\nwith<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              3.3 Workflow hierarchy<\/h2>\n\n\n
              Workflow\n|\n+-- name\n+-- on\n+-- permissions\n+-- jobs\n    |\n    +-- test\n        |\n        +-- runs-on\n        +-- steps\n            |\n            +-- checkout\n            +-- command\n<\/code><\/span><\/pre>\n\n\n
              3.4 name<\/code><\/h2>\n\n\n\n
              The workflow display name:<\/p>\n\n\n
              name<\/span>: Pull Request CI\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
              This appears in the Actions UI.<\/p>\n\n\n\n
              3.5 on<\/code><\/h2>\n\n\n\n
              The trigger:<\/p>\n\n\n
              on:\n  push:\n<\/code><\/span><\/pre>\n\n\n
              Or multiple triggers:<\/p>\n\n\n
              on:\n  push:\n  pull_request:\n  workflow_dispatch:\n<\/code><\/span><\/pre>\n\n\n
              3.6 jobs<\/code><\/h2>\n\n\n\n
              A workflow contains one or more jobs:<\/p>\n\n\n
              jobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - run: npm test\n<\/code><\/span><\/pre>\n\n\n
              Here test<\/code> is the job ID.<\/p>\n\n\n\n
              3.7 runs-on<\/code><\/h2>\n\n\n\n
              This selects the runner:<\/p>\n\n\n
              runs-on<\/span>: ubuntu-latest\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
              3.8 steps<\/code><\/h2>\n\n\n\n
              Steps run in order inside one job:<\/p>\n\n\n
              steps:\n  - run: echo<\/span> \"Step 1\"<\/span>\n  - run: echo<\/span> \"Step 2\"<\/span>\n  - run: echo<\/span> \"Step 3\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              3.9 uses<\/code><\/h2>\n\n\n\n
              Use a reusable Action:<\/p>\n\n\n
              - uses: actions\/checkout@v6\n<\/code><\/span><\/pre>\n\n\n
              3.10 run<\/code><\/h2>\n\n\n\n
              Run a shell command:<\/p>\n\n\n
              - run: npm test\n<\/code><\/span><\/pre>\n\n\n
              Multiline commands:<\/p>\n\n\n
              - name: Build\n  run: |\n    npm ci\n    npm test\n    npm run build\n<\/code><\/span><\/pre>\n\n\n
              3.11 with<\/code><\/h2>\n\n\n\n
              Pass inputs to an Action:<\/p>\n\n\n
              - uses: actions\/setup-node@v7\n  with<\/span>:\n    node-version: \"24\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              3.12 Micro-practice<\/h2>\n\n\n\n
              Modify your first workflow:<\/p>\n\n\n
              name: My First CI Workflow\n\non:\n  push:\n\njobs:\n  hello:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Print<\/span> repository information\n        run: |\n          echo<\/span> \"Repository: $GITHUB_REPOSITORY\"<\/span>\n          echo<\/span> \"Commit: $GITHUB_SHA\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              Push the change and inspect the log.<\/p>\n\n\n\n
              \n\n\n\n
              4. Events and Triggers<\/h1>\n\n\n\n
              A workflow does nothing until an event matches its on<\/code> configuration.<\/p>\n\n\n\n
              For a two-hour course, focus on three triggers:<\/p>\n\n\n
              push\npull_request\nworkflow_dispatch\n<\/code><\/span><\/pre>\n\n\n
              4.1 Push<\/h2>\n\n\n\n
              Run whenever code is pushed:<\/p>\n\n\n
              on:\n  push:\n<\/code><\/span><\/pre>\n\n\n
              Run only when main<\/code> changes:<\/p>\n\n\n
              on:\n  push:\n    branches:\n      - main\n<\/code><\/span><\/pre>\n\n\n
              Run for multiple branches:<\/p>\n\n\n
              on:\n  push:\n    branches:\n      - main\n      - develop\n<\/code><\/span><\/pre>\n\n\n
              4.2 Pull request<\/h2>\n\n\n\n
              Run when a pull request is opened or updated:<\/p>\n\n\n
              on:\n  pull_request:\n<\/code><\/span><\/pre>\n\n\n
              This is one of the most important CI triggers.<\/p>\n\n\n\n
              Typical PR workflow:<\/p>\n\n\n
              Developer creates PR\n        |\n        v\nGitHub starts CI\n        |\n        v\nLint\n        |\n        v\nTest\n        |\n        v\nBuild\n        |\n        v\nStatus check passes or fails\n<\/code><\/span><\/pre>\n\n\n
              4.3 Manual workflow<\/h2>\n\n\n\n
              Use workflow_dispatch<\/code> when a person should start the workflow manually:<\/p>\n\n\n
              on:\n  workflow_dispatch:\n<\/code><\/span><\/pre>\n\n\n
              After pushing the workflow to the default branch, GitHub can show a “Run workflow” button in the Actions UI.<\/p>\n\n\n\n
              A simple manual input:<\/p>\n\n\n
              on:\n  workflow_dispatch:\n    inputs:\n      environment:\n        description: Deployment environment\n        required<\/span>: true<\/span>\n        type<\/span>: choice\n        options<\/span>:\n          - staging\n          - production\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              Read the selected value with:<\/p>\n\n\n
              ${{ inputs.environment }}\n<\/code><\/span><\/pre>\n\n\n
              4.4 Multiple triggers<\/h2>\n\n\n\n
              A common CI workflow:<\/p>\n\n\n
              on<\/span>:\n  push<\/span>:\n    branches<\/span>: [main]<\/span>\n  pull_request<\/span>:\n  workflow_dispatch<\/span>:\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
              Meaning:<\/p>\n\n\n
              Push to main --------+\n                     |\nPull request --------+--> Run workflow\n                     |\nManual execution ----+\n<\/code><\/span><\/pre>\n\n\n
              4.5 Path filters<\/h2>\n\n\n\n
              If you only want CI when application code changes:<\/p>\n\n\n
              on:\n  pull_request:\n    paths:\n      - \"src\/**\"<\/span>\n      - \"package.json\"<\/span>\n      - \"package-lock.json\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              Use path filters carefully. A workflow skipped because of a path filter can interact with required checks in ways that need deliberate repository design.<\/p>\n\n\n\n
              4.6 Trigger practice<\/h2>\n\n\n\n
              Change your workflow so that it runs:<\/p>\n\n\n\n
                \n
              • on pull requests;<\/li>\n\n\n\n
              • on pushes to\u00a0main<\/code>;<\/li>\n\n\n\n
              • manually.<\/li>\n<\/ul>\n\n\n\n
                Solution:<\/p>\n\n\n
                on<\/span>:\n  push<\/span>:\n    branches<\/span>: [main]<\/span>\n  pull_request<\/span>:\n  workflow_dispatch<\/span>:\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                \n\n\n\n
                5. Jobs, Steps, and Runners<\/h1>\n\n\n\n
                This is the most important execution concept after triggers.<\/p>\n\n\n\n
                5.1 Jobs<\/h2>\n\n\n\n
                A job is an independently scheduled unit of work.<\/p>\n\n\n\n
                Example:<\/p>\n\n\n
                jobs:\n  lint:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Linting\"<\/span>\n\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Testing\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                By default, these jobs can run in parallel.<\/p>\n\n\n\n
                             +--> Job: lint --> Runner A\nWorkflow ----+\n             +--> Job: test --> Runner B\n<\/code><\/pre>\n\n\n\n
                5.2 Steps<\/h2>\n\n\n\n
                Steps inside a job run sequentially.<\/p>\n\n\n
                steps:\n  - run: echo<\/span> \"1\"<\/span>\n  - run: echo<\/span> \"2\"<\/span>\n  - run: echo<\/span> \"3\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                Execution:<\/p>\n\n\n
                Step 1\n  |\n  v\nStep 2\n  |\n  v\nStep 3\n<\/code><\/span><\/pre>\n\n\n
                5.3 Jobs do not automatically share files<\/h2>\n\n\n\n
                Each job normally has its own runner environment.<\/p>\n\n\n\n
                This is important:<\/p>\n\n\n
                Job A filesystem != Job B filesystem\n<\/code><\/span><\/pre>\n\n\n
                If one job creates a file and another job needs it, use an artifact or another explicit data-transfer mechanism.<\/p>\n\n\n\n
                5.4 Sequential jobs with needs<\/code><\/h2>\n\n\n\n
                Example:<\/p>\n\n\n
                jobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Build\"<\/span>\n\n  deploy:\n    needs: build\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Deploy\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                Flow:<\/p>\n\n\n
                Build\n  |\n  v\nDeploy\n<\/code><\/span><\/pre>\n\n\n
                Without needs<\/code>, jobs may run in parallel.<\/p>\n\n\n\n
                5.5 Fan-out pattern<\/h2>\n\n\n
                jobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Build\"<\/span>\n\n  unit:\n    needs: build\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Unit tests\"<\/span>\n\n  integration:\n    needs: build\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Integration tests\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                Flow:<\/p>\n\n\n\n
                            +--> Unit\n            |\nBuild ------+\n            |\n            +--> Integration\n<\/code><\/pre>\n\n\n\n
                5.6 Runners<\/h2>\n\n\n\n
                A runner is the compute environment that executes a job.<\/p>\n\n\n\n
                Common options:<\/p>\n\n\n\n
                Runner<\/th>Meaning<\/th><\/tr><\/thead>
                ubuntu-latest<\/code><\/td>GitHub-hosted Linux runner<\/td><\/tr>
                windows-latest<\/code><\/td>GitHub-hosted Windows runner<\/td><\/tr>
                macos-latest<\/code><\/td>GitHub-hosted macOS runner<\/td><\/tr>
                self-hosted<\/code><\/td>Runner managed by you<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                For this course, use:<\/p>\n\n\n
                runs-on<\/span>: ubuntu-latest\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                5.7 GitHub-hosted runners<\/h2>\n\n\n\n
                Advantages:<\/p>\n\n\n\n
                  \n
                • no server maintenance;<\/li>\n\n\n\n
                • fresh environment per job;<\/li>\n\n\n\n
                • common tools preinstalled;<\/li>\n\n\n\n
                • easy scaling;<\/li>\n\n\n\n
                • simple for most CI use cases.<\/li>\n<\/ul>\n\n\n\n
                  Important consequence:<\/p>\n\n\n\n
                  The environment is temporary. Do not expect files to remain after the job ends unless you upload them somewhere.<\/p>\n\n\n\n
                  5.8 Self-hosted runners<\/h2>\n\n\n\n
                  A self-hosted runner is a machine you operate.<\/p>\n\n\n\n
                  Examples:<\/p>\n\n\n\n
                    \n
                  • EC2 instance;<\/li>\n\n\n\n
                  • VM;<\/li>\n\n\n\n
                  • bare-metal server;<\/li>\n\n\n\n
                  • on-premises server;<\/li>\n\n\n\n
                  • Kubernetes runner pod.<\/li>\n<\/ul>\n\n\n\n
                    Use self-hosted runners when you need special networking, hardware, tooling, or internal access.<\/p>\n\n\n\n
                    For beginners, the most important security lesson is:<\/p>\n\n\n\n
                    \n
                    Do not run untrusted code on a powerful persistent self-hosted runner that can access production systems.<\/p>\n<\/blockquote>\n\n\n\n
                    5.9 Practice<\/h2>\n\n\n\n
                    Create two jobs:<\/p>\n\n\n
                    jobs:\n  lint:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Lint\"<\/span>\n\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Test\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Run the workflow and inspect whether the jobs overlap in time.<\/p>\n\n\n\n
                    Then add:<\/p>\n\n\n
                    needs<\/span>: lint\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                    to the test<\/code> job and run it again.<\/p>\n\n\n\n
                    Observe the difference.<\/p>\n\n\n\n
                    \n\n\n\n
                    6. Using Actions<\/h1>\n\n\n\n
                    An Action is reusable automation used inside a step.<\/p>\n\n\n\n
                    6.1 Action vs command<\/h2>\n\n\n\n
                    Action:<\/p>\n\n\n
                    - uses: actions\/checkout@v6\n<\/code><\/span><\/pre>\n\n\n
                    Command:<\/p>\n\n\n
                    - run: npm test\n<\/code><\/span><\/pre>\n\n\n
                    The difference is simple:<\/p>\n\n\n
                    uses = reuse an Action\nrun  = execute a shell command\n<\/code><\/span><\/pre>\n\n\n
                    6.2 Checkout Action<\/h2>\n\n\n\n
                    Most workflows need the repository contents:<\/p>\n\n\n
                    - name: Checkout\n  uses: actions\/checkout@v6\n<\/code><\/span><\/pre>\n\n\n
                    Without checkout, your runner does not automatically have the repository files available for your commands.<\/p>\n\n\n\n
                    6.3 Setup Actions<\/h2>\n\n\n\n
                    Example for Node.js:<\/p>\n\n\n
                    - name: Setup Node\n  uses<\/span>: actions\/setup-node@v7\n  with<\/span>:\n    node-version: \"24\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Example for Python:<\/p>\n\n\n
                    - name: Setup Python\n  uses<\/span>: actions\/setup-python@v5\n  with<\/span>:\n    python-version: \"3.13\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    6.4 Action inputs<\/h2>\n\n\n\n
                    Actions can accept inputs through with<\/code>:<\/p>\n\n\n
                    - uses: actions\/setup-node@v7\n  with<\/span>:\n    node-version: \"24\"<\/span>\n    cache<\/span>: npm\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    6.5 Action versions<\/h2>\n\n\n\n
                    Examples commonly use a major release tag:<\/p>\n\n\n
                    uses<\/span>: actions\/checkout@v6\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Production security-sensitive third-party Actions should be reviewed carefully and often pinned to a full commit SHA according to your organization’s supply-chain policy.<\/p>\n\n\n\n
                    The beginner rule is:<\/p>\n\n\n\n
                      \n
                    • prefer official or well-reviewed Actions;<\/li>\n\n\n\n
                    • understand what permissions they receive;<\/li>\n\n\n\n
                    • do not blindly copy random Marketplace Actions into privileged workflows.<\/li>\n<\/ul>\n\n\n\n
                      \n\n\n\n
                      7. Variables, Contexts, and Expressions<\/h1>\n\n\n\n
                      These concepts often confuse beginners because they look similar.<\/p>\n\n\n\n
                      Use this table first:<\/p>\n\n\n\n
                      Type<\/th>Example<\/th>Purpose<\/th><\/tr><\/thead>
                      Environment variable<\/td>$NODE_ENV<\/code><\/td>Runtime process configuration<\/td><\/tr>
                      Configuration variable<\/td>${{ vars.API_URL }}<\/code><\/td>Non-secret GitHub configuration<\/td><\/tr>
                      Context<\/td>${{ github.ref }}<\/code><\/td>Runtime information from GitHub<\/td><\/tr>
                      Expression<\/td>${{ ... }}<\/code><\/td>GitHub-side evaluation and logic<\/td><\/tr>
                      Secret<\/td>${{ secrets.API_TOKEN }}<\/code><\/td>Sensitive configuration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      7.1 Environment variables<\/h2>\n\n\n\n
                      Workflow-level:<\/p>\n\n\n
                      env:\n  NODE_ENV: test\n<\/code><\/span><\/pre>\n\n\n
                      Job-level:<\/p>\n\n\n
                      jobs:\n  test:\n    env:\n      MODE: ci\n<\/code><\/span><\/pre>\n\n\n
                      Step-level:<\/p>\n\n\n
                      - name: Run test\n  env<\/span>:\n    API_URL: https:\/\/example.test<\/span>\n  run: npm test\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      A more specific scope overrides a broader scope.<\/p>\n\n\n\n
                      7.2 Default GitHub environment variables<\/h2>\n\n\n\n
                      GitHub automatically provides many useful values.<\/p>\n\n\n\n
                      Examples:<\/p>\n\n\n
                      GITHUB_REPOSITORY\nGITHUB_SHA\nGITHUB_REF\nGITHUB_REF_NAME\nGITHUB_RUN_ID\nGITHUB_RUN_NUMBER\nGITHUB_WORKFLOW\nGITHUB_WORKSPACE\nRUNNER_OS\nRUNNER_ARCH\n<\/code><\/span><\/pre>\n\n\n
                      Use them in shell commands:<\/p>\n\n\n
                      - name: Print<\/span> metadata\n  run: |\n    echo<\/span> \"Repository: $GITHUB_REPOSITORY\"<\/span>\n    echo<\/span> \"Commit: $GITHUB_SHA\"<\/span>\n    echo<\/span> \"Ref: $GITHUB_REF\"<\/span>\n    echo<\/span> \"Runner: $RUNNER_OS\/$RUNNER_ARCH\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                      7.3 Contexts<\/h2>\n\n\n\n
                      Contexts are structured objects evaluated by GitHub.<\/p>\n\n\n\n
                      Important contexts:<\/p>\n\n\n\n
                      Context<\/th>Example data<\/th><\/tr><\/thead>
                      github<\/code><\/td>repository, ref, SHA, actor, event<\/td><\/tr>
                      env<\/code><\/td>workflow\/job\/step environment values<\/td><\/tr>
                      vars<\/code><\/td>configuration variables<\/td><\/tr>
                      secrets<\/code><\/td>available secrets<\/td><\/tr>
                      steps<\/code><\/td>step outputs and outcomes<\/td><\/tr>
                      needs<\/code><\/td>dependency job results and outputs<\/td><\/tr>
                      matrix<\/code><\/td>current matrix values<\/td><\/tr>
                      runner<\/code><\/td>runner details<\/td><\/tr>
                      inputs<\/code><\/td>manual or reusable workflow inputs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      Example:<\/p>\n\n\n
                      - run: |\n    echo<\/span> \"Repository: ${{ github.repository }}\"<\/span>\n    echo<\/span> \"Branch: ${{ github.ref_name }}\"<\/span>\n    echo<\/span> \"Commit: ${{ github.sha }}\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                      7.4 Expressions<\/h2>\n\n\n\n
                      GitHub expression syntax:<\/p>\n\n\n
                      ${{ expression }}\n<\/code><\/span><\/pre>\n\n\n
                      Example:<\/p>\n\n\n
                      if<\/span>: ${{ github.ref == 'refs\/heads\/main'<\/span> }}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      In many if:<\/code> conditions, the outer ${{ }}<\/code> is optional:<\/p>\n\n\n
                      if<\/span>: github.ref == 'refs\/heads\/main'<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      7.5 Useful operators<\/h2>\n\n\n
                      ==\n!=\n&&\n||\n!\n<\/code><\/span><\/pre>\n\n\n
                      Example:<\/p>\n\n\n
                      if<\/span>: github.ref == 'refs\/heads\/main'<\/span> && github.event_name == 'push'<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      7.6 Useful functions<\/h2>\n\n\n\n
                      Examples:<\/p>\n\n\n
                      if<\/span>: startsWith(github.ref, 'refs\/tags\/v'<\/span>)\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
                      if<\/span>: contains(github.event.pull_request.labels.*.name, 'run-full-ci'<\/span>)\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
                      key: npm-${{ runner.os }}-${{ hashFiles('**\/package-lock.json'<\/span>) }}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                      You do not need to memorize all expression functions. Learn how to recognize and look them up.<\/p>\n\n\n\n
                      7.7 Conditions<\/h2>\n\n\n\n
                      A common conditional step:<\/p>\n\n\n
                      - name: Main branch only\n  if<\/span>: github.ref == 'refs\/heads\/main'<\/span>\n  run: echo<\/span> \"Running on main\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                      Common status functions:<\/p>\n\n\n
                      if<\/span>: success()\nif<\/span>: failure()\nif<\/span>: cancelled()\nif<\/span>: always()\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                      Example cleanup:<\/p>\n\n\n
                      - name: Collect diagnostics\n  if<\/span>: failure()\n  run: echo<\/span> \"Tests failed - collecting diagnostics\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                      \n\n\n\n
                      8. Secrets and GITHUB_TOKEN<\/h1>\n\n\n\n
                      Secrets and permissions are where beginner workflows can accidentally become unsafe.<\/p>\n\n\n\n
                      8.1 What is a secret?<\/h2>\n\n\n\n
                      A secret is sensitive information stored in GitHub instead of being written directly into the workflow file.<\/p>\n\n\n\n
                      Examples:<\/p>\n\n\n\n
                        \n
                      • API tokens;<\/li>\n\n\n\n
                      • passwords;<\/li>\n\n\n\n
                      • package registry tokens;<\/li>\n\n\n\n
                      • signing credentials;<\/li>\n\n\n\n
                      • webhook tokens.<\/li>\n<\/ul>\n\n\n\n
                        Do not do this:<\/p>\n\n\n
                        env:\n  API_TOKEN: abc123-real-secret\n<\/code><\/span><\/pre>\n\n\n
                        Instead, create a GitHub secret and reference it:<\/p>\n\n\n
                        env:\n  API_TOKEN: ${{ secrets.API_TOKEN }}\n<\/code><\/span><\/pre>\n\n\n
                        8.2 Secret scopes<\/h2>\n\n\n\n
                        Secrets can be configured at different scopes, including:<\/p>\n\n\n\n
                          \n
                        • repository;<\/li>\n\n\n\n
                        • organization;<\/li>\n\n\n\n
                        • environment.<\/li>\n<\/ul>\n\n\n\n
                          For beginners, repository secrets are the easiest to understand.<\/p>\n\n\n\n
                          For deployments, environment secrets are often better because production and staging can use different credentials.<\/p>\n\n\n\n
                          8.3 Using a secret safely<\/h2>\n\n\n\n
                          Prefer passing a secret as environment data:<\/p>\n\n\n
                          - name: Call API\n  env:\n    API_TOKEN: ${{ secrets.API_TOKEN }}\n  run: .\/call-api.sh\n<\/code><\/span><\/pre>\n\n\n
                          Avoid printing secrets:<\/p>\n\n\n
                          echo<\/span> \"$API_TOKEN\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                          GitHub masks many known secret values in logs, but masking should not be treated as a complete data-loss prevention system.<\/p>\n\n\n\n
                          8.4 Fork pull requests<\/h2>\n\n\n\n
                          Untrusted pull requests do not automatically receive powerful repository secrets.<\/p>\n\n\n\n
                          That is intentional.<\/p>\n\n\n\n
                          The safe mental model is:<\/p>\n\n\n
                          Untrusted pull request\n        |\n        v\nLow-privilege CI\n        |\n        v\nTest \/ validate\n        |\n        v\nTrusted workflow handles privileged work\n<\/code><\/span><\/pre>\n\n\n
                          Do not design ordinary PR testing so that arbitrary code requires production credentials.<\/p>\n\n\n\n
                          8.5 What is GITHUB_TOKEN<\/code>?<\/h2>\n\n\n\n
                          GitHub automatically creates a short-lived token for workflow jobs.<\/p>\n\n\n\n
                          You usually do not need to manually create or rotate it.<\/p>\n\n\n\n
                          A workflow can access it as:<\/p>\n\n\n
                          ${{ secrets.GITHUB_TOKEN }}\n<\/code><\/span><\/pre>\n\n\n
                          or:<\/p>\n\n\n
                          ${{ github.token }}\n<\/code><\/span><\/pre>\n\n\n
                          8.6 Permissions<\/h2>\n\n\n\n
                          Always start with the minimum permissions required.<\/p>\n\n\n\n
                          A safe CI baseline:<\/p>\n\n\n
                          permissions:\n  contents: read\n<\/code><\/span><\/pre>\n\n\n
                          A job that needs to create or modify repository content may need more:<\/p>\n\n\n
                          permissions:\n  contents: write\n<\/code><\/span><\/pre>\n\n\n
                          Do not grant write permission to every job just because one job needs it.<\/p>\n\n\n\n
                          8.7 Workflow-level vs job-level permissions<\/h2>\n\n\n\n
                          Example:<\/p>\n\n\n
                          permissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Read-only CI\"<\/span>\n\n  publish:\n    permissions:\n      contents: write\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Publishing needs additional permission\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                          This keeps the test job less privileged.<\/p>\n\n\n\n
                          8.8 Beginner security rule<\/h2>\n\n\n\n
                          Remember:<\/p>\n\n\n
                          Secrets protect sensitive values.\nPermissions control what the workflow identity can do<\/span>.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          They solve different problems.<\/p>\n\n\n\n
                          \n\n\n\n
                          9. Hands-On Lab: Build Your First CI Pipeline<\/h1>\n\n\n\n
                          This is the main practical exercise.<\/p>\n\n\n\n
                          You will build one CI workflow step by step.<\/p>\n\n\n\n
                          The example assumes a Node.js project with commands similar to:<\/p>\n\n\n
                          npm ci\nnpm run lint\nnpm test\nnpm run build\n<\/code><\/span><\/pre>\n\n\n
                          If your project uses different commands, adapt them.<\/p>\n\n\n\n
                          9.1 Goal<\/h2>\n\n\n\n
                          By the end, the workflow will look like this:<\/p>\n\n\n
                          Push \/ Pull Request\n        |\n        v\nCheckout\n        |\n        v\nSetup Node.js\n        |\n        v\nInstall dependencies\n        |\n        v\nLint\n        |\n        v\nTest\n        |\n        v\nBuild\n        |\n        v\nUpload build artifact\n<\/code><\/span><\/pre>\n\n\n
                          9.2 Step 1 – Create the workflow<\/h2>\n\n\n\n
                          Create:<\/p>\n\n\n
                          .github\/workflows\/ci.yml\n<\/code><\/span><\/pre>\n\n\n
                          Start with:<\/p>\n\n\n
                          name: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  ci:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Say hello\n        run: echo<\/span> \"Starting CI\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Commit and push.<\/p>\n\n\n\n
                          Confirm that the workflow starts.<\/p>\n\n\n\n
                          9.3 Step 2 – Checkout the repository<\/h2>\n\n\n\n
                          Replace the hello-only workflow with:<\/p>\n\n\n
                          name<\/span>: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  ci:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v6\n\n      - name: List repository files\n        run: ls -la\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Run it.<\/p>\n\n\n\n
                          The ls -la<\/code> command should now show repository files.<\/p>\n\n\n\n
                          9.4 Step 3 – Setup Node.js<\/h2>\n\n\n\n
                          Add:<\/p>\n\n\n
                          - name: Setup Node\n  uses<\/span>: actions\/setup-node@v7\n  with<\/span>:\n    node-version: \"24\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Then verify:<\/p>\n\n\n
                          - name: Check Node version\n  run: node --version\n<\/code><\/span><\/pre>\n\n\n
                          Your steps now include:<\/p>\n\n\n
                          steps:\n  - name: Checkout\n    uses<\/span>: actions\/checkout@v6\n\n  - name: Setup Node\n    uses<\/span>: actions\/setup-node@v7\n    with<\/span>:\n      node-version: \"24\"<\/span>\n\n  - name: Check Node version\n    run<\/span>: node --version\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          9.5 Step 4 – Install dependencies<\/h2>\n\n\n\n
                          Add:<\/p>\n\n\n
                          - name: Install dependencies\n  run: npm ci\n<\/code><\/span><\/pre>\n\n\n
                          Why npm ci<\/code> instead of npm install<\/code> in CI?<\/p>\n\n\n\n
                          npm ci<\/code> is designed for clean, repeatable installation based on the lock file.<\/p>\n\n\n\n
                          9.6 Step 5 – Lint<\/h2>\n\n\n\n
                          Add:<\/p>\n\n\n
                          - name: Lint\n  run: npm run lint\n<\/code><\/span><\/pre>\n\n\n
                          If linting fails, the job normally stops and the workflow fails.<\/p>\n\n\n\n
                          That is desirable in CI when lint is a required quality gate.<\/p>\n\n\n\n
                          9.7 Step 6 – Test<\/h2>\n\n\n\n
                          Add:<\/p>\n\n\n
                          - name: Test\n  run: npm test\n<\/code><\/span><\/pre>\n\n\n
                          Now the pipeline validates behavior, not only syntax\/style.<\/p>\n\n\n\n
                          9.8 Step 7 – Build<\/h2>\n\n\n\n
                          Add:<\/p>\n\n\n
                          - name: Build\n  run: npm run build\n<\/code><\/span><\/pre>\n\n\n
                          A successful run now proves:<\/p>\n\n\n
                          Repository can be checked out\nDependencies can be installed\nCode passes lint\nTests pass\nApplication can build\n<\/code><\/span><\/pre>\n\n\n
                          9.9 Step 8 – Add a timeout<\/h2>\n\n\n\n
                          Jobs should not run forever.<\/p>\n\n\n\n
                          Add:<\/p>\n\n\n
                          timeout-minutes<\/span>: 15\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Example:<\/p>\n\n\n
                          jobs:\n  ci:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15\n<\/code><\/span><\/pre>\n\n\n
                          9.10 Step 9 – Final baseline CI workflow<\/h2>\n\n\n
                          name<\/span>: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  ci:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15\n\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v6\n\n      - name: Setup Node\n        uses: actions\/setup-node@v7\n        with:\n          node-version: \"24\"\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Lint\n        run: npm run lint\n\n      - name: Test\n        run: npm test\n\n      - name: Build\n        run: npm run build\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                          9.11 What happens when npm test<\/code> fails?<\/h2>\n\n\n\n
                          Execution normally looks like:<\/p>\n\n\n
                          Checkout ........ PASS\nSetup Node ...... PASS\nInstall ......... PASS\nLint ............ PASS\nTest ............ FAIL\nBuild ........... NOT RUN\nWorkflow ........ FAIL\n<\/code><\/span><\/pre>\n\n\n
                          That is standard fail-fast behavior for sequential steps.<\/p>\n\n\n\n
                          9.12 Add diagnostics on failure<\/h2>\n\n\n\n
                          Add:<\/p>\n\n\n
                          - name: Failure diagnostics\n  if<\/span>: failure()\n  run: |\n    echo<\/span> \"A previous step failed\"<\/span>\n    echo<\/span> \"Commit: $GITHUB_SHA\"<\/span>\n    echo<\/span> \"Runner: $RUNNER_OS\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                          This introduces conditional steps.<\/p>\n\n\n\n
                          9.13 Add concurrency for pull request CI<\/h2>\n\n\n\n
                          When developers push several commits quickly, old CI runs can become wasteful.<\/p>\n\n\n\n
                          Add at workflow level:<\/p>\n\n\n
                          concurrency:\n  group: ci-${{ github.workflow }}-${{ github.ref }}\n  cancel-in<\/span>-progress: true<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Complete baseline:<\/p>\n\n\n
                          name: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\npermissions:\n  contents: read\n\nconcurrency:\n  group: ci-${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true<\/span>\n\njobs:\n  ci:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15<\/span>\n\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v6\n\n      - name: Setup Node\n        uses: actions\/setup-node@v7\n        with:\n          node-version: \"24\"<\/span>\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Lint\n        run: npm run lint\n\n      - name: Test\n        run: npm test\n\n      - name: Build\n        run: npm run build\n\n      - name: Failure diagnostics\n        if<\/span>: failure()\n        run: |\n          echo<\/span> \"CI failed\"<\/span>\n          echo<\/span> \"Commit: $GITHUB_SHA\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                          You now have a useful real-world CI workflow.<\/p>\n\n\n\n
                          \n\n\n\n
                          10. Matrix Builds<\/h1>\n\n\n\n
                          A matrix allows one job definition to run multiple combinations.<\/p>\n\n\n\n
                          10.1 Why use a matrix?<\/h2>\n\n\n\n
                          Suppose your application supports Node.js 22 and 24.<\/p>\n\n\n\n
                          Without a matrix, you could create two nearly identical jobs.<\/p>\n\n\n\n
                          That duplicates YAML.<\/p>\n\n\n\n
                          With a matrix:<\/p>\n\n\n
                          strategy<\/span>:\n  matrix<\/span>:\n    node<\/span>: [22, 24]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                          GitHub expands the job.<\/p>\n\n\n
                          Test job\n   |\n   +--> Node 22\n   |\n   +--> Node 24\n<\/code><\/span><\/pre>\n\n\n
                          10.2 Basic matrix workflow<\/h2>\n\n\n
                          name<\/span>: Matrix CI\n\non:\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    strategy:\n      matrix:\n        node: [22, 24]\n\n    steps:\n      - uses: actions\/checkout@v6\n\n      - uses: actions\/setup-node@v7\n        with:\n          node-version: ${{ matrix.node }}\n\n      - run: npm ci\n      - run: npm test\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                          GitHub creates separate jobs for the matrix values.<\/p>\n\n\n\n
                          10.3 Multi-dimensional matrices<\/h2>\n\n\n\n
                          Example:<\/p>\n\n\n
                          strategy:\n  matrix:\n    os: [ubuntu-latest, windows-latest]\n    node: [22, 24]\n\nruns-on: ${{ matrix.os }}\n<\/code><\/span><\/pre>\n\n\n
                          This expands to four combinations:<\/p>\n\n\n\n
                          OS<\/th>Node<\/th><\/tr><\/thead>
                          Ubuntu<\/td>22<\/td><\/tr>
                          Ubuntu<\/td>24<\/td><\/tr>
                          Windows<\/td>22<\/td><\/tr>
                          Windows<\/td>24<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                          Do not create large matrices just because you can. Every combination costs time and compute.<\/p>\n\n\n\n
                          10.4 fail-fast<\/code><\/h2>\n\n\n\n
                          If one matrix job fails, GitHub can cancel other in-progress matrix jobs according to strategy behavior.<\/p>\n\n\n\n
                          If you want all compatibility results:<\/p>\n\n\n
                          strategy:\n  fail-fast: false<\/span>\n  matrix<\/span>:\n    node: [22<\/span>, 24<\/span>]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          10.5 Beginner rule<\/h2>\n\n\n\n
                          Use a matrix when you are testing the same logic against multiple supported environments.<\/p>\n\n\n\n
                          Do not use a matrix merely to make YAML look advanced.<\/p>\n\n\n\n
                          \n\n\n\n
                          11. Caching<\/h1>\n\n\n\n
                          Caching speeds up workflows by reusing data that is expensive to download or compute.<\/p>\n\n\n\n
                          11.1 Mental model<\/h2>\n\n\n
                          Without cache:\nDownload dependencies -> run build\n\nWith cache hit:\nRestore dependency cache -> run build\n<\/code><\/span><\/pre>\n\n\n
                          A cache is a performance optimization.<\/p>\n\n\n\n
                          Your build should still be correct if the cache disappears.<\/p>\n\n\n\n
                          11.2 Node.js dependency caching<\/h2>\n\n\n\n
                          The simplest approach uses setup-node<\/code>:<\/p>\n\n\n
                          - name: Setup Node\n  uses<\/span>: actions\/setup-node@v7\n  with<\/span>:\n    node-version: \"24\"<\/span>\n    cache<\/span>: npm\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Then:<\/p>\n\n\n
                          - run: npm ci\n<\/code><\/span><\/pre>\n\n\n
                          The cache reduces repeated dependency download work.<\/p>\n\n\n\n
                          11.3 Cache keys<\/h2>\n\n\n\n
                          For manual caching, keys usually include information that determines whether cached content is valid.<\/p>\n\n\n\n
                          Example concept:<\/p>\n\n\n
                          OS + runtime + dependency lock hash\n<\/code><\/span><\/pre>\n\n\n
                          Example:<\/p>\n\n\n
                          key: npm-${{ runner.os }}-${{ hashFiles('**\/package-lock.json'<\/span>) }}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          11.4 Cache vs artifact<\/h2>\n\n\n\n
                          Do not confuse them.<\/p>\n\n\n\n
                          Cache<\/th>Artifact<\/th><\/tr><\/thead>
                          Speeds up future work<\/td>Preserves workflow output<\/td><\/tr>
                          Usually dependencies\/build cache<\/td>Usually packages\/reports\/build output<\/td><\/tr>
                          Correctness should not depend on it<\/td>Can be part of the delivery pipeline<\/td><\/tr>
                          Looked up by cache key<\/td>Uploaded\/downloaded by artifact name or ID<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                          11.5 Cache security<\/h2>\n\n\n\n
                          Cached content can become a supply-chain risk if untrusted workflows can poison caches later consumed by privileged jobs.<\/p>\n\n\n\n
                          Beginner rule:<\/p>\n\n\n\n
                          \n
                          Treat cache as untrusted performance data, not as proof that software is safe.<\/p>\n<\/blockquote>\n\n\n\n
                          \n\n\n\n
                          12. Artifacts<\/h1>\n\n\n\n
                          Artifacts are files produced by a workflow and stored by GitHub.<\/p>\n\n\n\n
                          Examples:<\/p>\n\n\n\n
                            \n
                          • compiled application;<\/li>\n\n\n\n
                          • coverage report;<\/li>\n\n\n\n
                          • test report;<\/li>\n\n\n\n
                          • generated documentation;<\/li>\n\n\n\n
                          • packaged release candidate;<\/li>\n\n\n\n
                          • diagnostic logs.<\/li>\n<\/ul>\n\n\n\n
                            12.1 Upload an artifact<\/h2>\n\n\n\n
                            If your build creates dist\/<\/code>:<\/p>\n\n\n
                            - name: Upload build artifact\n  uses: actions\/upload-artifact@v4\n  with:\n    name: application\n    path: dist\/\n<\/code><\/span><\/pre>\n\n\n
                            12.2 Add artifact upload to the lab<\/h2>\n\n\n\n
                            Update your CI workflow:<\/p>\n\n\n
                            - name: Build\n  run: npm run build\n\n- name: Upload build artifact\n  uses: actions\/upload-artifact@v4\n  with:\n    name: application-${{ github.sha }}\n    path: dist\/\n    retention-days: 7\n<\/code><\/span><\/pre>\n\n\n
                            Now the flow becomes:<\/p>\n\n\n
                            Checkout\n   |\nSetup\n   |\nInstall\n   |\nLint\n   |\nTest\n   |\nBuild\n   |\nUpload artifact\n<\/code><\/span><\/pre>\n\n\n
                            12.3 Download in another job<\/h2>\n\n\n\n
                            A separate job can download the artifact:<\/p>\n\n\n
                            deploy:\n  needs: ci\n  runs-on: ubuntu-latest\n\n  steps:\n    - name: Download build\n      uses: actions\/download-artifact@v5\n      with:\n        name: application-${{ github.sha }}\n        path: dist\/\n\n    - name: Inspect\n      run: ls -la dist\/\n<\/code><\/span><\/pre>\n\n\n
                            12.4 Build once, deploy many<\/h2>\n\n\n\n
                            A mature CI\/CD design often creates one immutable artifact and promotes that exact artifact.<\/p>\n\n\n
                            Commit\n  |\n  v\nBuild once\n  |\n  v\nArtifact\n  |\n  +--> Staging\n  |\n  +--> UAT\n  |\n  +--> Production\n<\/code><\/span><\/pre>\n\n\n
                            This is better than rebuilding different binaries independently for each environment when consistency matters.<\/p>\n\n\n\n
                            \n\n\n\n
                            13. From CI to CD and Environments<\/h1>\n\n\n\n
                            Once CI proves the code is acceptable, CD moves a release toward an environment.<\/p>\n\n\n\n
                            13.1 Basic lifecycle<\/h2>\n\n\n
                            Developer\n   |\n   v\nPush \/ Pull Request\n   |\n   v\nCI\n   |\n   +--> Lint\n   +--> Test\n   +--> Build\n   |\n   v\nArtifact\n   |\n   v\nStaging\n   |\n   v\nApproval \/ Protection\n   |\n   v\nProduction\n<\/code><\/span><\/pre>\n\n\n
                            13.2 GitHub environments<\/h2>\n\n\n\n
                            A GitHub environment can represent a deployment target such as:<\/p>\n\n\n
                            development\nstaging\nuat\nproduction\n<\/code><\/span><\/pre>\n\n\n
                            Environments can be used with:<\/p>\n\n\n\n
                              \n
                            • environment secrets;<\/li>\n\n\n\n
                            • environment variables;<\/li>\n\n\n\n
                            • deployment approvals;<\/li>\n\n\n\n
                            • branch restrictions;<\/li>\n\n\n\n
                            • deployment protection rules;<\/li>\n\n\n\n
                            • deployment history.<\/li>\n<\/ul>\n\n\n\n
                              13.3 Reference an environment<\/h2>\n\n\n
                              deploy:\n  needs: build\n  runs-on: ubuntu-latest\n  environment: production\n\n  steps:\n    - run: .\/deploy.sh\n<\/code><\/span><\/pre>\n\n\n
                              13.4 A safer deployment shape<\/h2>\n\n\n
                              jobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v6\n      - run: .\/build.sh\n      - uses: actions\/upload-artifact@v4\n        with:\n          name: release\n          path: dist\/\n\n  deploy:\n    needs: build\n    runs-on: ubuntu-latest\n    environment: production\n\n    steps:\n      - uses: actions\/download-artifact@v5\n        with:\n          name: release\n          path: dist\/\n\n      - run: .\/deploy.sh dist\/\n<\/code><\/span><\/pre>\n\n\n
                              The key design idea is:<\/p>\n\n\n
                              Build first\nVerify first\nThen deploy\n<\/code><\/span><\/pre>\n\n\n
                              13.5 Approvals<\/h2>\n\n\n\n
                              A production environment can require reviewers before a deployment job receives protected environment access.<\/p>\n\n\n\n
                              Conceptually:<\/p>\n\n\n
                              Deployment requested\n       |\n       v\nEnvironment gate\n       |\n       +--> Rejected --> Stop\n       |\n       +--> Approved --> Deploy\n<\/code><\/span><\/pre>\n\n\n
                              For a two-hour course, understand the concept. Detailed environment governance belongs in the advanced course.<\/p>\n\n\n\n
                              \n\n\n\n
                              14. GitHub Actions Security: 5 Rules<\/h1>\n\n\n\n
                              If students remember only five security rules, use these.<\/p>\n\n\n\n
                              Rule 1 – Use least privilege<\/h2>\n\n\n\n
                              Start with:<\/p>\n\n\n
                              permissions:\n  contents: read\n<\/code><\/span><\/pre>\n\n\n
                              Add write permissions only when a specific job needs them.<\/p>\n\n\n\n
                              Bad beginner habit:<\/p>\n\n\n
                              permissions<\/span>: write-all\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                              Avoid broad permissions unless there is a strong, reviewed reason.<\/p>\n\n\n\n
                              Rule 2 – Never hard-code secrets<\/h2>\n\n\n\n
                              Bad:<\/p>\n\n\n
                              env:\n  PASSWORD: my-password-123\n<\/code><\/span><\/pre>\n\n\n
                              Good:<\/p>\n\n\n
                              env:\n  PASSWORD: ${{ secrets.PASSWORD }}\n<\/code><\/span><\/pre>\n\n\n
                              Rule 3 – Do not print secrets<\/h2>\n\n\n\n
                              Bad:<\/p>\n\n\n
                              echo<\/span> \"$PASSWORD\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                              Also avoid writing secrets into artifacts or caches.<\/p>\n\n\n\n
                              Rule 4 – Treat Actions as code dependencies<\/h2>\n\n\n\n
                              An Action can execute code in your job.<\/p>\n\n\n\n
                              That means an Action may be able to access:<\/p>\n\n\n\n
                                \n
                              • repository files;<\/li>\n\n\n\n
                              • available secrets;<\/li>\n\n\n\n
                              • job token permissions;<\/li>\n\n\n\n
                              • the network;<\/li>\n\n\n\n
                              • workflow outputs.<\/li>\n<\/ul>\n\n\n\n
                                Prefer trusted Actions and review third-party Actions before allowing them into privileged workflows.<\/p>\n\n\n\n
                                Rule 5 – Treat pull request input as untrusted<\/h2>\n\n\n\n
                                This can be dangerous:<\/p>\n\n\n
                                - run: echo<\/span> \"${{ github.event.pull_request.title }}\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                Why?<\/p>\n\n\n\n
                                A pull request title is user-controlled data. Interpolating untrusted values directly into shell syntax can create command-injection risks.<\/p>\n\n\n\n
                                Safer:<\/p>\n\n\n
                                - name: Print<\/span> title safely\n  env:\n    PR_TITLE: ${{ github.event.pull_request.title }}\n  run: printf '%s\\n'<\/span> \"$PR_TITLE\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                The general rule is:<\/p>\n\n\n
                                Untrusted input should be treated as<\/span> data,\nnot as<\/span> executable shell syntax.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                14.1 One more critical PR rule<\/h2>\n\n\n\n
                                pull_request<\/code> and pull_request_target<\/code> are not interchangeable.<\/p>\n\n\n\n
                                For beginner CI that executes pull request code, prefer a low-privilege pull_request<\/code> workflow.<\/p>\n\n\n\n
                                Do not combine a privileged base-repository context with execution of untrusted pull request code unless you fully understand the security model.<\/p>\n\n\n\n
                                \n\n\n\n
                                15. Troubleshooting: The 7-Step Method<\/h1>\n\n\n\n
                                Do not debug GitHub Actions by randomly editing YAML.<\/p>\n\n\n\n
                                Use layers.<\/p>\n\n\n\n
                                15.1 Debugging flow<\/h2>\n\n\n
                                Problem\n  |\n  v\n1. Did workflow start?\n  |\n  +-- No --> Trigger \/ branch \/ path \/ YAML\n  |\n  +-- Yes\n        |\n        v\n2. Did job start?\n        |\n        +-- No --> needs \/ if \/ runner \/ environment\n        |\n        +-- Yes\n              |\n              v\n3. Which step failed?\n              |\n              v\n4. Read first useful error\n              |\n              v\n5. Classify error\n              |\n      +-------+-------+-------+-------+\n      |       |       |       |       |\n    YAML   Command  Auth   Network  Runtime\n<\/code><\/span><\/pre>\n\n\n
                                15.2 Step 1 – Did the workflow start?<\/h2>\n\n\n\n
                                If no workflow run appears, check:<\/p>\n\n\n\n
                                  \n
                                • Is the file under\u00a0.github\/workflows\/<\/code>?<\/li>\n\n\n\n
                                • Is the YAML valid?<\/li>\n\n\n\n
                                • Did the expected event happen?<\/li>\n\n\n\n
                                • Does\u00a0on<\/code>\u00a0match the event?<\/li>\n\n\n\n
                                • Does the branch filter match?<\/li>\n\n\n\n
                                • Does the path filter match?<\/li>\n\n\n\n
                                • Is the workflow enabled?<\/li>\n<\/ul>\n\n\n\n
                                  15.3 Step 2 – Did the job start?<\/h2>\n\n\n\n
                                  If the workflow exists but a job is skipped or queued, check:<\/p>\n\n\n\n
                                    \n
                                  • if<\/code>\u00a0condition;<\/li>\n\n\n\n
                                  • needs<\/code>\u00a0dependency;<\/li>\n\n\n\n
                                  • runner label;<\/li>\n\n\n\n
                                  • environment approval;<\/li>\n\n\n\n
                                  • runner availability.<\/li>\n<\/ul>\n\n\n\n
                                    15.4 Step 3 – Which step failed?<\/h2>\n\n\n\n
                                    Open the failing job and locate the first failed step.<\/p>\n\n\n\n
                                    Avoid focusing only on the last red line. The useful error may appear earlier.<\/p>\n\n\n\n
                                    15.5 Step 4 – Is it YAML or application logic?<\/h2>\n\n\n\n
                                    Example workflow error:<\/p>\n\n\n
                                    Invalid workflow file\n<\/code><\/span><\/pre>\n\n\n
                                    Usually means syntax, indentation, expression, or unsupported configuration.<\/p>\n\n\n\n
                                    Example application error:<\/p>\n\n\n
                                    npm test exited with<\/span> code 1<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                    That may mean the workflow works correctly but the test failed.<\/p>\n\n\n\n
                                    This distinction matters.<\/p>\n\n\n\n
                                    15.6 Step 5 – Check authentication and permissions<\/h2>\n\n\n\n
                                    Useful mental model:<\/p>\n\n\n
                                    401 = authentication problem is likely\n403 = identity exists but permission\/policy may deny\n404 = resource may not exist or may be hidden by authorization\n<\/code><\/span><\/pre>\n\n\n
                                    Check:<\/p>\n\n\n\n
                                      \n
                                    • permissions<\/code>;<\/li>\n\n\n\n
                                    • secret availability;<\/li>\n\n\n\n
                                    • token scope;<\/li>\n\n\n\n
                                    • environment approval;<\/li>\n\n\n\n
                                    • fork restrictions.<\/li>\n<\/ul>\n\n\n\n
                                      15.7 Step 6 – Check the runner environment<\/h2>\n\n\n\n
                                      Print selected values:<\/p>\n\n\n
                                      - name: Runner diagnostics\n  run: |\n    echo<\/span> \"OS=$RUNNER_OS\"<\/span>\n    echo<\/span> \"ARCH=$RUNNER_ARCH\"<\/span>\n    echo<\/span> \"WORKSPACE=$GITHUB_WORKSPACE\"<\/span>\n    pwd\n    df -h\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                      For self-hosted runners also check:<\/p>\n\n\n\n
                                        \n
                                      • runner online status;<\/li>\n\n\n\n
                                      • labels;<\/li>\n\n\n\n
                                      • disk space;<\/li>\n\n\n\n
                                      • network access;<\/li>\n\n\n\n
                                      • service health;<\/li>\n\n\n\n
                                      • file permissions.<\/li>\n<\/ul>\n\n\n\n
                                        15.8 Step 7 – Reproduce the failing command<\/h2>\n\n\n\n
                                        If this fails in Actions:<\/p>\n\n\n
                                        - run: npm test\n<\/code><\/span><\/pre>\n\n\n
                                        try to reproduce the same command with the same runtime and dependencies locally or in a controlled container.<\/p>\n\n\n\n
                                        The workflow may simply be exposing a real application issue.<\/p>\n\n\n\n
                                        15.9 Common mistakes<\/h2>\n\n\n\n
                                        Symptom<\/th>Likely cause<\/th><\/tr><\/thead>
                                        Workflow does not run<\/td>Trigger\/filter\/path\/YAML issue<\/td><\/tr>
                                        Job is skipped<\/td>if<\/code> or failed needs<\/code> dependency<\/td><\/tr>
                                        Job stays queued<\/td>No matching runner or capacity<\/td><\/tr>
                                        command not found<\/code><\/td>Tool missing or PATH issue<\/td><\/tr>
                                        File missing in second job<\/td>Jobs do not share filesystem<\/td><\/tr>
                                        Secret empty<\/td>Secret unavailable in that context\/scope<\/td><\/tr>
                                        API returns 403<\/td>Token lacks permission<\/td><\/tr>
                                        Cache always misses<\/td>Bad key or changing inputs<\/td><\/tr>
                                        Artifact missing<\/td>Wrong path or build did not create file<\/td><\/tr>
                                        Works locally, fails in CI<\/td>Environment\/runtime\/dependency difference<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                        \n\n\n\n
                                        16. Final Hands-On Challenge<\/h1>\n\n\n\n
                                        Start with this incomplete workflow:<\/p>\n\n\n
                                        name: CI\n\non:\n  push:\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions\/checkout@v6\n\n      - run: echo<\/span> \"TODO\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Complete as many tasks as possible without copying the final solution.<\/p>\n\n\n\n
                                        Challenge tasks<\/h2>\n\n\n\n
                                          \n
                                        1. Add the\u00a0pull_request<\/code>\u00a0trigger.<\/li>\n\n\n\n
                                        2. Make\u00a0push<\/code>\u00a0run only for\u00a0main<\/code>.<\/li>\n\n\n\n
                                        3. Add\u00a0workflow_dispatch<\/code>.<\/li>\n\n\n\n
                                        4. Add\u00a0permissions: contents: read<\/code>.<\/li>\n\n\n\n
                                        5. Add a 15-minute job timeout.<\/li>\n\n\n\n
                                        6. Setup Node.js 24.<\/li>\n\n\n\n
                                        7. Enable npm caching.<\/li>\n\n\n\n
                                        8. Run\u00a0npm ci<\/code>.<\/li>\n\n\n\n
                                        9. Run\u00a0npm run lint<\/code>.<\/li>\n\n\n\n
                                        10. Run\u00a0npm test<\/code>.<\/li>\n\n\n\n
                                        11. Run\u00a0npm run build<\/code>.<\/li>\n\n\n\n
                                        12. Upload\u00a0dist\/<\/code>\u00a0as an artifact.<\/li>\n\n\n\n
                                        13. Name the artifact using\u00a0github.sha<\/code>.<\/li>\n\n\n\n
                                        14. Add a failure-diagnostics step.<\/li>\n\n\n\n
                                        15. Convert Node.js versions 22 and 24 into a matrix.<\/li>\n<\/ol>\n\n\n\n
                                          One possible solution<\/h2>\n\n\n
                                          name: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n  workflow_dispatch:\n\npermissions:\n  contents: read\n\nconcurrency:\n  group: ci-${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true<\/span>\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15<\/span>\n\n    strategy:\n      fail-fast: false<\/span>\n      matrix:\n        node: [22<\/span>, 24<\/span>]\n\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v6\n\n      - name: Setup Node\n        uses: actions\/setup-node@v7\n        with:\n          node-version: ${{ matrix.node }}\n          cache: npm\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Lint\n        run: npm run lint\n\n      - name: Test\n        run: npm test\n\n      - name: Build\n        run: npm run build\n\n      - name: Upload artifact\n        uses: actions\/upload-artifact@v4\n        with:\n          name: application-node-${{ matrix.node }}-${{ github.sha }}\n          path: dist\/\n          retention-days: 7<\/span>\n\n      - name: Failure diagnostics\n        if<\/span>: failure()\n        run: |\n          echo<\/span> \"Workflow: $GITHUB_WORKFLOW\"<\/span>\n          echo<\/span> \"Commit: $GITHUB_SHA\"<\/span>\n          echo<\/span> \"Runner: $RUNNER_OS\/$RUNNER_ARCH\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          If you can explain every line in this workflow, you have learned the essential GitHub Actions model.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          17. GitHub Actions Essential Cheat Sheet<\/h1>\n\n\n\n
                                          17.1 Workflow location<\/h2>\n\n\n
                                          .github\/workflows\/*.yml\n<\/code><\/span><\/pre>\n\n\n
                                          17.2 Minimal workflow<\/h2>\n\n\n
                                          name: CI\n\non:\n  push:\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo<\/span> \"Hello\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.3 Common triggers<\/h2>\n\n\n
                                          on:\n  push:\n  pull_request:\n  workflow_dispatch:\n<\/code><\/span><\/pre>\n\n\n
                                          17.4 Push only to main<\/h2>\n\n\n
                                          on<\/span>:\n  push<\/span>:\n    branches<\/span>: [main]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.5 Checkout<\/h2>\n\n\n
                                          - uses: actions\/checkout@v6\n<\/code><\/span><\/pre>\n\n\n
                                          17.6 Setup Node<\/h2>\n\n\n
                                          - uses: actions\/setup-node@v7\n  with<\/span>:\n    node-version: \"24\"<\/span>\n    cache<\/span>: npm\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.7 Run a command<\/h2>\n\n\n
                                          - run: npm test\n<\/code><\/span><\/pre>\n\n\n
                                          17.8 Multiline shell<\/h2>\n\n\n
                                          - run: |\n    npm ci\n    npm test\n    npm run build\n<\/code><\/span><\/pre>\n\n\n
                                          17.9 Job dependency<\/h2>\n\n\n
                                          needs<\/span>: build\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.10 Condition<\/h2>\n\n\n
                                          if<\/span>: github.ref == 'refs\/heads\/main'<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.11 Secret<\/h2>\n\n\n
                                          env:\n  API_TOKEN: ${{ secrets.API_TOKEN }}\n<\/code><\/span><\/pre>\n\n\n
                                          17.12 Read-only permissions<\/h2>\n\n\n
                                          permissions:\n  contents: read\n<\/code><\/span><\/pre>\n\n\n
                                          17.13 Context values<\/h2>\n\n\n
                                          ${{ github.repository }}\n${{ github.sha }}\n${{ github.ref_name }}\n<\/code><\/span><\/pre>\n\n\n
                                          17.14 Matrix<\/h2>\n\n\n
                                          strategy<\/span>:\n  matrix<\/span>:\n    node<\/span>: [22, 24]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          Use:<\/p>\n\n\n
                                          ${{ matrix.node }}\n<\/code><\/span><\/pre>\n\n\n
                                          17.15 Upload artifact<\/h2>\n\n\n
                                          - uses: actions\/upload-artifact@v4\n  with:\n    name: application\n    path: dist\/\n<\/code><\/span><\/pre>\n\n\n
                                          17.16 Download artifact<\/h2>\n\n\n
                                          - uses: actions\/download-artifact@v5\n  with:\n    name: application\n    path: dist\/\n<\/code><\/span><\/pre>\n\n\n
                                          17.17 Cancel stale CI<\/h2>\n\n\n
                                          concurrency:\n  group: ci-${{ github.workflow }}-${{ github.ref }}\n  cancel-in<\/span>-progress: true<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.18 Failure-only step<\/h2>\n\n\n
                                          - if<\/span>: failure()\n  run: echo<\/span> \"Something failed\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.19 Environment<\/h2>\n\n\n
                                          environment<\/span>: production\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          17.20 The five security rules<\/h2>\n\n\n
                                          1.<\/span> Least privilege.\n2.<\/span> Never hard-code secrets.\n3.<\/span> Never print<\/span> secrets.\n4.<\/span> Treat Actions as<\/span> executable dependencies.\n5.<\/span> Treat pull request input as<\/span> untrusted.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          \n\n\n\n
                                          18. 15-Question Knowledge Check<\/h1>\n\n\n\n
                                          Try to answer before reading the answer key.<\/p>\n\n\n\n
                                          Questions<\/h2>\n\n\n\n
                                          1. Where must GitHub Actions workflow files normally be stored?<\/h3>\n\n\n\n
                                          A. .github\/actions\/<\/code> B. .github\/workflows\/<\/code> C. .git\/workflows\/<\/code> D. workflows\/<\/code><\/p>\n\n\n\n
                                          2. What does on<\/code> define?<\/h3>\n\n\n\n
                                          A. The runner B. Workflow permissions C. Workflow triggers D. Workflow artifacts<\/p>\n\n\n\n
                                          3. What is the difference between a job and a step?<\/h3>\n\n\n\n
                                          4. Do two jobs automatically share the same filesystem?<\/h3>\n\n\n\n
                                          5. What does runs-on<\/code> select?<\/h3>\n\n\n\n
                                          6. What is the difference between uses<\/code> and run<\/code>?<\/h3>\n\n\n\n
                                          7. What does needs: build<\/code> do?<\/h3>\n\n\n\n
                                          8. Which should hold an API password?<\/h3>\n\n\n\n
                                          A. vars<\/code> B. secrets<\/code> C. github<\/code> D. runner<\/code><\/p>\n\n\n\n
                                          9. What does ${{ github.sha }}<\/code> represent?<\/h3>\n\n\n\n
                                          10. What problem does a matrix solve?<\/h3>\n\n\n\n
                                          11. What is the main purpose of a cache?<\/h3>\n\n\n\n
                                          12. What is the main purpose of an artifact?<\/h3>\n\n\n\n
                                          13. Why should workflow permissions be minimal?<\/h3>\n\n\n\n
                                          14. Why is direct interpolation of pull request titles into shell commands risky?<\/h3>\n\n\n\n
                                          15. If a workflow does not start at all, what should you check first?<\/h3>\n\n\n\n
                                          \n\n\n\n
                                          Answer key<\/h2>\n\n\n\n
                                          1. B – .github\/workflows\/<\/code><\/h3>\n\n\n\n
                                          That is the standard workflow directory.<\/p>\n\n\n\n
                                          2. C – Workflow triggers<\/h3>\n\n\n\n
                                          on<\/code> tells GitHub when the workflow is eligible to run.<\/p>\n\n\n\n
                                          3. Job vs step<\/h3>\n\n\n\n
                                          A job is independently scheduled to a runner. A step is one ordered task inside a job.<\/p>\n\n\n\n
                                          4. No<\/h3>\n\n\n\n
                                          Jobs normally run on separate runner environments. Use artifacts, outputs, or another explicit mechanism to transfer data.<\/p>\n\n\n\n
                                          5. The runner<\/h3>\n\n\n\n
                                          Example:<\/p>\n\n\n
                                          runs-on<\/span>: ubuntu-latest\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          6. uses<\/code> vs run<\/code><\/h3>\n\n\n\n
                                          uses<\/code> invokes an Action. run<\/code> executes a shell command.<\/p>\n\n\n\n
                                          7. It creates a dependency<\/h3>\n\n\n\n
                                          The dependent job waits for build<\/code> and normally only runs if the dependency succeeds.<\/p>\n\n\n\n
                                          8. B – secrets<\/code><\/h3>\n\n\n\n
                                          Sensitive values should not be ordinary configuration variables.<\/p>\n\n\n\n
                                          9. The commit SHA<\/h3>\n\n\n\n
                                          It identifies the commit associated with the workflow run.<\/p>\n\n\n\n
                                          10. Repeated compatibility combinations<\/h3>\n\n\n\n
                                          A matrix expands one job definition across multiple values such as runtime versions or operating systems.<\/p>\n\n\n\n
                                          11. Performance<\/h3>\n\n\n\n
                                          A cache reduces repeated download or computation work.<\/p>\n\n\n\n
                                          12. Retaining workflow output<\/h3>\n\n\n\n
                                          Artifacts preserve files such as build output, reports, or packages.<\/p>\n\n\n\n
                                          13. Reduce blast radius<\/h3>\n\n\n\n
                                          If a job or dependency is compromised, least privilege limits what the workflow identity can do.<\/p>\n\n\n\n
                                          14. Command injection risk<\/h3>\n\n\n\n
                                          Pull request metadata is user-controlled. It should be passed as data rather than inserted directly into executable shell syntax.<\/p>\n\n\n\n
                                          15. Trigger and workflow definition<\/h3>\n\n\n\n
                                          Check the workflow location, YAML validity, event, branch\/path filters, and whether the workflow is enabled.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          19. What to Learn Next<\/h1>\n\n\n\n
                                          After completing this tutorial, you should be comfortable with:<\/p>\n\n\n\n
                                            \n
                                          • workflows;<\/li>\n\n\n\n
                                          • triggers;<\/li>\n\n\n\n
                                          • jobs;<\/li>\n\n\n\n
                                          • steps;<\/li>\n\n\n\n
                                          • runners;<\/li>\n\n\n\n
                                          • Actions;<\/li>\n\n\n\n
                                          • variables;<\/li>\n\n\n\n
                                          • contexts;<\/li>\n\n\n\n
                                          • expressions;<\/li>\n\n\n\n
                                          • secrets;<\/li>\n\n\n\n
                                          • GITHUB_TOKEN<\/code>;<\/li>\n\n\n\n
                                          • permissions;<\/li>\n\n\n\n
                                          • matrix builds;<\/li>\n\n\n\n
                                          • caching;<\/li>\n\n\n\n
                                          • artifacts;<\/li>\n\n\n\n
                                          • basic CI\/CD flow;<\/li>\n\n\n\n
                                          • environments;<\/li>\n\n\n\n
                                          • security basics;<\/li>\n\n\n\n
                                          • troubleshooting basics.<\/li>\n<\/ul>\n\n\n\n
                                            The next learning sequence should be:<\/p>\n\n\n
                                            GitHub Actions Essentials\n        |\n        v\nReusable Workflows\n        |\n        v\nAdvanced Security\n        |\n        v\nOIDC \/ Cloud Authentication\n        |\n        v\nDocker CI\/CD\n        |\n        v\nCloud \/ Kubernetes Deployment\n        |\n        v\nInfrastructure as<\/span> Code\n        |\n        v\nSelf<\/span>-hosted Runners \/ ARC\n        |\n        v\nOrganization and<\/span> Enterprise Governance\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            19.1 Recommended next topics<\/h2>\n\n\n\n
                                            Reusable automation<\/h3>\n\n\n\n
                                            Learn:<\/p>\n\n\n\n
                                              \n
                                            • reusable workflows;<\/li>\n\n\n\n
                                            • composite actions;<\/li>\n\n\n\n
                                            • workflow inputs;<\/li>\n\n\n\n
                                            • workflow outputs;<\/li>\n\n\n\n
                                            • centralized CI standards.<\/li>\n<\/ul>\n\n\n\n
                                              Advanced security<\/h3>\n\n\n\n
                                              Learn:<\/p>\n\n\n\n
                                                \n
                                              • pull_request<\/code>\u00a0vs\u00a0pull_request_target<\/code>;<\/li>\n\n\n\n
                                              • third-party Action pinning;<\/li>\n\n\n\n
                                              • cache poisoning;<\/li>\n\n\n\n
                                              • supply-chain trust;<\/li>\n\n\n\n
                                              • branch protection;<\/li>\n\n\n\n
                                              • rulesets;<\/li>\n\n\n\n
                                              • environment protection.<\/li>\n<\/ul>\n\n\n\n
                                                Cloud authentication<\/h3>\n\n\n\n
                                                Learn OpenID Connect so workflows can obtain short-lived cloud credentials instead of storing long-lived cloud access keys.<\/p>\n\n\n\n
                                                Containers<\/h3>\n\n\n\n
                                                Learn:<\/p>\n\n\n\n
                                                  \n
                                                • Docker build and push;<\/li>\n\n\n\n
                                                • container registries;<\/li>\n\n\n\n
                                                • image tags and digests;<\/li>\n\n\n\n
                                                • image scanning;<\/li>\n\n\n\n
                                                • SBOMs;<\/li>\n\n\n\n
                                                • provenance.<\/li>\n<\/ul>\n\n\n\n
                                                  Kubernetes<\/h3>\n\n\n\n
                                                  Learn:<\/p>\n\n\n\n
                                                    \n
                                                  • secure cluster authentication;<\/li>\n\n\n\n
                                                  • Helm or Kustomize;<\/li>\n\n\n\n
                                                  • rollout verification;<\/li>\n\n\n\n
                                                  • namespace and identity isolation;<\/li>\n\n\n\n
                                                  • GitOps patterns.<\/li>\n<\/ul>\n\n\n\n
                                                    Infrastructure as Code<\/h3>\n\n\n\n
                                                    Learn a controlled pipeline such as:<\/p>\n\n\n
                                                    fmt\n |\n v\nvalidate\n |\n v\nsecurity checks\n |\n v\nplan\n |\n v\nreview \/ approval\n |\n v\napply\n<\/code><\/span><\/pre>\n\n\n
                                                    Runner architecture<\/h3>\n\n\n\n
                                                    Learn:<\/p>\n\n\n\n
                                                      \n
                                                    • self-hosted runners;<\/li>\n\n\n\n
                                                    • ephemeral runners;<\/li>\n\n\n\n
                                                    • runner groups;<\/li>\n\n\n\n
                                                    • private networking;<\/li>\n\n\n\n
                                                    • Actions Runner Controller;<\/li>\n\n\n\n
                                                    • trust-zone separation.<\/li>\n<\/ul>\n\n\n\n
                                                      \n\n\n\n
                                                      Final Summary<\/h1>\n\n\n\n
                                                      If you remember only one model, remember this:<\/p>\n\n\n
                                                      Event\n  |\n  v\nWorkflow\n  |\n  v\nJobs\n  |\n  v\nRunners\n  |\n  v\nSteps\n  |\n  v\nActions \/ Commands\n<\/code><\/span><\/pre>\n\n\n
                                                      And if you remember only one production pipeline shape, remember this:<\/p>\n\n\n
                                                      Change\n  |\n  v\nCI Trigger\n  |\n  v\nCheckout\n  |\n  v\nInstall\n  |\n  v\nLint\n  |\n  v\nTest\n  |\n  v\nBuild\n  |\n  v\nArtifact\n  |\n  v\nProtected<\/span> Deployment\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                      And if you remember only one security principle:<\/p>\n\n\n\n
                                                      \n
                                                      Give every workflow, job, runner, Action, and credential only the access it actually needs.<\/p>\n<\/blockquote>\n\n\n\n
                                                      That foundation is enough to start building useful GitHub Actions workflows safely and confidently.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                                      Audience: Beginners, developers, junior DevOps engineers, QA engineers, and students Level: Beginner to early-intermediate Duration: About 120 minutes Format: Learn, modify, run, break, and fix Goal: By… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-78744","post","type-post","status-publish","format-standard","hentry","category-best-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78744","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=78744"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78744\/revisions"}],"predecessor-version":[{"id":78745,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78744\/revisions\/78745"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=78744"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=78744"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=78744"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}