Ship code that proves it is safe

Why this course exists

Most tutorials stop at "your tests ran green". Real companies need more: they must show that the code was reviewed, that no secret leaked, that the container has no critical vulnerability, that the image running in production is exactly the one the pipeline built, and who approved the deployment. That is DevSecOps: security checks built into the delivery pipeline instead of a review at the end.

This course takes a real repository, georgesmomo/devsecops-actions-lab, and explains it from the ground up. It starts with the GitHub interface (no prior knowledge needed), then goes deep into GitHub Actions, supply chain security, settings, GitHub Apps, AI agents, and finally the GH-200 certification.

What the lab contains

A tiny Python web API (two endpoints), a Dockerfile, two Kubernetes manifests, and six workflows. The application is deliberately simple so that all your attention goes to the delivery chain around it. One dependency, gunicorn==22.0.0, is intentionally old so that Dependabot and Trivy have something real to report.

Three ways to use this course

The core vocabulary

The global bar

The bar at the top of every page does not depend on the repository you are in. Learn it once, use it everywhere.

The menu (global navigation)

The + button

The Copilot menu

The avatar menu

The tabs under the repository name are a map of everything GitHub does for a project. Here they are on the lab repository.

The Code page

The green Code button

Creating an issue from a template

Templates live in .github/ISSUE_TEMPLATE/. The lab contains a YAML form, bug.yml. The "Report a security vulnerability" option appears because the repository has a SECURITY.md and private reporting.

name: Bug
description: Report a malfunction
labels: [bug]              # added automatically1
body:
  - type: textarea
    id: what
    attributes:
      label: What is happening?
    validations:
      required: true       # enforced by the web form only2
  - type: input
    id: run
    attributes:
      label: Link to the GitHub Actions run (if any)

1. Every issue created with this form gets the bug label, so triage filters work from day one.
2. The API can still create an issue without this field: validation is a web-form feature.

The repository's files carry French comments; excerpts in this course show them translated.

The pull request list

Minutes after the repository was created, Dependabot opened two pull requests: it spotted the deliberately old gunicorn==22.0.0 and a newer Python base image.

Anatomy of a pull request

# Sensitive files require the owner's review (with "Require review from Code Owners")
*                       @georgesmomo
/.github/               @georgesmomo
/Dockerfile             @georgesmomo

name: Feature request
description: Propose an improvement
labels: [enhancement]
body:
  - type: textarea
    id: problem
    attributes:
      label: Problem to solve
    validations:
      required: true

blank_issues_enabled: false

The whole lab was pushed from the web interface, without a local git. Three screens are enough.

A new repository

The workflow editor

Opening a file under .github/workflows/ turns on a special editor: autocompletion for Actions keys, schema validation, and a Marketplace panel that inserts an action's snippet for you.

Committing

name: Hello
on:
  push:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Event $GITHUB_EVENT_NAME on $GITHUB_REF_NAME"

The building blocks

Triggers: when does a workflow run?

The on: block is a filter on events. Here is the real trigger block of the main pipeline.

on:
  push:
    branches: [main]
    tags: ["v*.*.*"]                 # a release tag also starts the pipeline1
    paths:                           # ...but only if these files changed2
      - "app/**"
      - "Dockerfile"
      - "k8s/**"
      - ".github/workflows/devsecops.yml"
      - ".github/workflows/reusable-docker.yml"
      - ".github/workflows/ci.yml"
      - ".github/actions/**"
  workflow_dispatch:                 # the Run workflow button3
    inputs:
      environment:
        description: "Target environment"
        type: choice
        options: [staging, production]
        default: staging
      skip-deploy:
        description: "Build without deploying"
        type: boolean
        default: false

1. When a push contains both branch and tag filters, matching either one is enough. Pushing v1.2.0 produces an image tagged 1.2.0.
2. With paths, a commit that only edits the README does not start the pipeline. Path filters are not evaluated for tag pushes.
3. Manual runs with typed inputs, read later as ${{ inputs.environment }}.

Contexts and expressions

Anything between ${{ }} is an expression, evaluated by GitHub before the step runs. Expressions read contexts: objects that describe the run.

Useful functions: status checks success(), failure(), always(), cancelled(); text and data contains(), startsWith(), format(), join(), toJSON(), fromJSON(), and hashFiles() for cache keys. The lab builds its run summary with join(fromJSON(steps.meta.outputs.json).tags, ', '): turn the JSON output of an action into a list, then into a comma-separated string.

Passing data: step to step, job to job

jobs:
  build:
    outputs:                                     # job outputs, readable by other jobs2
      digest: ${{ steps.push.outputs.digest }}
      image: ${{ steps.vars.outputs.image }}
    steps:
      - name: Lower-case image name
        id: vars
        run: echo "image=ghcr.io/${GITHUB_REPOSITORY,,}" >> "$GITHUB_OUTPUT"   # step output1

  deploy:
    needs: build
    env:
      IMAGE: ${{ needs.build.outputs.image }}@${{ needs.build.outputs.digest }}   # read in another job3

1. A step writes key=value to the file named by $GITHUB_OUTPUT. ${GITHUB_REPOSITORY,,} is bash for "lower-case", because registry names must be lower-case.
2. The job promotes step outputs to job outputs.
3. Any job that needs it can read them. For files rather than strings, use artifacts.

The matrix: one definition, many jobs

  test:
    name: Tests (Python ${{ matrix.python }})
    needs: lint
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false                 # let the other version finish if one fails1
      matrix:
        python: ["3.12", "3.13"]       # two jobs generated2
    defaults:
      run:
        working-directory: app
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
        with:
          python-version: ${{ matrix.python }}
          cache: pip                   # built-in dependency cache3
          cache-dependency-path: app/requirements-dev.txt
      - run: pip install -r requirements-dev.txt
      - run: pytest --junitxml=report-${{ matrix.python }}.xml
      - name: Publish the test report
        if: always()                   # upload even when tests fail4
        uses: actions/upload-artifact@cf430e030ddbb5b0abf93d22962f4752f3646cd9 # v7.0.2
        with:
          name: test-report-${{ matrix.python }}
          path: app/report-${{ matrix.python }}.xml
          retention-days: 7

1. By default fail-fast is true: the first failure cancels the rest of the matrix.
2. Add axes (OS, versions) and the jobs multiply: 2 OS × 3 versions = 6 jobs. include adds a combination, exclude removes one, max-parallel limits concurrency.
3. The cache key is derived from the dependency file: change the file, get a new cache.
4. if: always() makes this step run even after a failure, which is exactly when you want the report.

Concurrency: one run at a time

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true      # a new push to the same branch cancels the obsolete run

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false     # never interrupt a deployment in progress

Three ways to reuse

name: Smoke test Kubernetes
description: Expose a Service through port-forward and check the HTTP answer
inputs:
  service:
    description: Name of the Kubernetes Service
    required: true
  path:
    default: /healthz
  expected:
    default: ok
outputs:
  response:
    value: ${{ steps.call.outputs.response }}
runs:
  using: composite                     # steps, not jobs1
  steps:
    - name: HTTP call
      id: call
      shell: bash                      # mandatory for run steps in a composite2
      env:
        SVC: ${{ inputs.service }}     # inputs go through env, never straight into the script3
        URL_PATH: ${{ inputs.path }}
        EXPECTED: ${{ inputs.expected }}
      run: |
        kubectl port-forward "svc/${SVC}" 18080:80 >/tmp/pf.log 2>&1 &
        for i in $(seq 1 20); do
          if body=$(curl -fsS "http://127.0.0.1:18080${URL_PATH}"); then break; fi
          sleep 2
        done
        echo "response=${body}" >> "$GITHUB_OUTPUT"
        if [[ "${body}" != *"${EXPECTED}"* ]]; then
          echo "::error title=Smoke test::unexpected answer on ${URL_PATH}"
          exit 1
        fi

1. Three action types exist: JavaScript (using: node24, fast, every OS), Docker (using: docker, Linux only, frozen environment) and composite.
2. Every run step of a composite action must declare its shell.
3. The same anti-injection habit as in workflows.

    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest]
        python: ["3.12", "3.13"]
        exclude:
          - os: windows-latest
            python: "3.12"

jobs:
  version:
    runs-on: ubuntu-latest
    outputs:
      short: ${{ steps.v.outputs.short }}
    steps:
      - id: v
        run: echo "short=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
  announce:
    needs: version
    runs-on: ubuntu-latest
    steps:
      - env:
          SHORT: ${{ needs.version.outputs.short }}
        run: echo "Building commit $SHORT"

Starting a run by hand

The run graph

Job summaries

Logs

The same from the terminal

Everything in the Actions tab is also available with the GitHub CLI, gh. These are the commands you will use most.

$ gh run list --workflow devsecops.yml --limit 5
$ gh run watch
$ gh run view --log-failed
$ gh run rerun --failed
$ gh workflow run devsecops.yml -f environment=staging -f skip-deploy=true
$ gh run download -n sbom.spdx.json
$ gh cache list

gh run view, rerun and download ask you to pick a run when you do not pass its ID.

The actions lockfile

The map of the repository

The orchestrator

permissions: {}                      # zero rights by default1
concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false
jobs:
  ci:
    uses: ./.github/workflows/ci.yml           # reused CI2
    permissions:
      contents: read
      pull-requests: write
  build:
    needs: ci
    uses: ./.github/workflows/reusable-docker.yml
    with:
      push: true
    permissions:                     # exactly what the build needs3
      contents: read
      packages: write
      security-events: write
      id-token: write                # OIDC for Sigstore
      attestations: write
      artifact-metadata: write
  deploy:
    needs: build
    if: ${{ !inputs.skip-deploy }}
    environment:
      name: ${{ inputs.environment || 'staging' }}4
    permissions:
      contents: read
      packages: read
      attestations: read
    env:
      IMAGE: ${{ needs.build.outputs.image }}@${{ needs.build.outputs.digest }}   # by digest5

1. The workflow grants nothing; each job asks for its own permissions. A compromised step in the deploy job cannot push an image.
2. The same ci.yml serves pull requests and the pipeline: one definition to maintain.
3. A reusable workflow cannot get more permissions than the caller grants.
4. On a push there are no inputs, so the expression falls back to staging.
5. Everything after the build refers to the immutable digest, never to a tag.

What happens, and why

1. Filtered trigger. A README change does not restart the pipeline thanks to paths. A v1.2.0 tag does, and produces an image tagged 1.2.0.
2. Reused CI. The same ci.yml runs on pull requests and inside the pipeline.
3. Scan before publishing. The image is built locally (load: true), scanned, and only pushed if the gate passes. The second build reuses the type=gha cache, so it costs seconds.
4. Sign the digest, never the tag. latest can move; sha256:… cannot.
5. Zero trust at deployment. The deploy job re-verifies the cosign signature and the SLSA provenance before loading the image into kind.
6. Proof of life. The composite action calls /healthz and fails the job if the answer is wrong.

Inside the reusable build

      - name: Build (local)
        uses: docker/build-push-action@c3c9e263c25d99ce0380d002d59b67737d91b0dc # v7.4.0
        with:
          context: .
          load: true                   # keep the image on the runner, do not push
          tags: lab-api:scan
          build-args: APP_VERSION=${{ github.sha }}
          cache-from: type=gha         # GitHub Actions cache for Docker layers
          cache-to: type=gha,mode=max

      - name: Trivy - SARIF report
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
        with:
          image-ref: lab-api:scan
          format: sarif
          output: trivy.sarif
          ignore-unfixed: true
          exit-code: "0"               # report everything, never fail here
      - name: Upload SARIF to code scanning
        if: always()
        uses: github/codeql-action/upload-sarif@6f2ac81f5cd81fe351a197ba0b00d91d03cd2aee # v4.39.0
        with:
          sarif_file: trivy.sarif
          category: trivy-image
      - name: Trivy - CRITICAL gate
        uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25 # v0.36.0
        with:
          image-ref: lab-api:scan
          severity: CRITICAL
          ignore-unfixed: true         # only vulnerabilities you can actually fix
          exit-code: "1"               # fail the job: this is the gate
          skip-setup-trivy: true

      - name: Login GHCR
        if: inputs.push
        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}   # no personal token needed
      - name: Build & push
        id: push
        if: inputs.push
        uses: docker/build-push-action@c3c9e263c25d99ce0380d002d59b67737d91b0dc # v7.4.0
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}     # sha-…, main, 1.2.0, latest
          labels: ${{ steps.meta.outputs.labels }}
          build-args: APP_VERSION=${{ github.sha }}
          cache-from: type=gha

      - name: SBOM (Syft, SPDX)
        uses: anchore/sbom-action@66cbf4bc1f1c0d2edc94016e65bc221b6bb0ad6c # v0.24.3
        with:
          image: ${{ steps.vars.outputs.image }}@${{ steps.push.outputs.digest }}
          format: spdx-json
          output-file: sbom.spdx.json
      - uses: sigstore/cosign-installer@6f9f17788090df1f26f669e9d70d6ae9567deba6 # v4.1.2
      - name: Keyless signature (cosign + OIDC)
        run: cosign sign --yes "${{ steps.vars.outputs.image }}@${{ steps.push.outputs.digest }}"
      - name: Provenance attestation (SLSA)
        uses: actions/attest@1e69f48acb82d1966a394da916b4c1698aa569d6 # v4.2.2
        with:
          subject-name: ${{ steps.vars.outputs.image }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true
      - name: SBOM attestation
        uses: actions/attest@1e69f48acb82d1966a394da916b4c1698aa569d6 # v4.2.2
        with:
          subject-name: ${{ steps.vars.outputs.image }}
          subject-digest: ${{ steps.push.outputs.digest }}
          sbom-path: sbom.spdx.json
          push-to-registry: true

Keyless signing, the chain of trust

      - name: Verify the cosign signature
        run: |
          cosign verify "$IMAGE" \
            --certificate-identity-regexp "^https://github.com/${GITHUB_REPOSITORY}/" \
            --certificate-oidc-issuer https://token.actions.githubusercontent.com > /dev/null
          echo "Valid signature for $IMAGE"
      - name: Verify the provenance attestation
        env:
          GH_TOKEN: ${{ github.token }}
        run: gh attestation verify "oci://$IMAGE" --repo "$GITHUB_REPOSITORY"
      - name: Create an ephemeral Kubernetes cluster (kind)
        uses: helm/kind-action@1544676c07bb3570fcb70166beaa07c4528fd4aa # v1.15.1
      - name: Load the verified image into the cluster
        run: |
          docker pull "$IMAGE"
          docker tag "$IMAGE" "$LOCAL_TAG"
          kind load docker-image "$LOCAL_TAG" --name chart-testing
      - name: Deploy
        run: |
          sed -i "s|IMAGE_PLACEHOLDER|${LOCAL_TAG}|" k8s/deployment.yaml
          kubectl apply -f k8s/
          kubectl rollout status deployment/lab-api --timeout=180s
      - name: Smoke test
        uses: ./.github/actions/smoke-test
        with:
          service: lab-api

The container and the cluster

FROM python:3.13-slim AS build                       # stage 1: install dependencies1
WORKDIR /src
COPY app/requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

FROM python:3.13-slim                                # stage 2: minimal final image
LABEL org.opencontainers.image.source="https://github.com/georgesmomo/devsecops-actions-lab"2
RUN useradd --create-home --uid 10001 appuser
COPY --from=build /install /usr/local
COPY app/app.py .
USER 10001                                           # never run as root3
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s CMD python -c "import urllib.request,sys; urllib.request.urlopen('http://127.0.0.1:8080/healthz'); sys.exit(0)"
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "--workers", "2", "app:app"]

1. A multi-stage build keeps compilers and caches out of the final image: smaller, fewer vulnerabilities.
2. This label links the GHCR package to the repository (permissions, README, provenance).
3. A numeric user ID lets Kubernetes verify runAsNonRoot.

    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: api
          image: IMAGE_PLACEHOLDER          # replaced by the pipeline
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true    # the app cannot modify its own files1
            capabilities: { drop: ["ALL"] }
          volumeMounts: [{ name: tmp, mountPath: /tmp }]   # the only writable place2
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }
          resources:
            requests: { cpu: 50m, memory: 64Mi }
            limits: { cpu: 250m, memory: 128Mi }

1. If an attacker gets code execution, they cannot drop tools into the container's file system.
2. gunicorn needs a writable temporary folder, so /tmp is an in-memory emptyDir.

To learn Kubernetes itself in the same hands-on style, take the Kubernetes + Helm course of this series.

The other guards

    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0       # the whole history: a deleted secret is still in git
      - uses: gitleaks/gitleaks-action@e0c47f4f8be36e29cdc102c57e68cb5cbf0e8d1e # v3.0.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  dependency-review:
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      - uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0
        with:
          fail-on-severity: high          # block a PR that adds a vulnerable dependency
          comment-summary-in-pr: always

on:
  push: { branches: [main] }
  pull_request: { branches: [main] }
  schedule:
    - cron: "27 3 * * 1"        # every Monday 03:27 UTC: new rules, new alerts
jobs:
  analyze:
    permissions:
      contents: read
      actions: read
      security-events: write    # publish alerts to the Security tab
    strategy:
      matrix:
        language: [python, actions]   # the workflows are analyzed too
    steps:
      - uses: github/codeql-action/init@6f2ac81f5cd81fe351a197ba0b00d91d03cd2aee # v4.39.0
        with:
          languages: ${{ matrix.language }}
          queries: security-extended
      - uses: github/codeql-action/analyze@6f2ac81f5cd81fe351a197ba0b00d91d03cd2aee # v4.39.0

version: 2
updates:
  - package-ecosystem: pip
    directory: /app
    schedule: { interval: weekly }
  - package-ecosystem: docker
    directory: /
    schedule: { interval: weekly }
  - package-ecosystem: github-actions   # also updates pinned SHAs and their comments
    directory: /
    schedule: { interval: weekly }
    groups:
      actions:
        patterns: ["*"]                 # one pull request for all actions

Practice: run the whole loop

The published image

The provenance attestation

You can verify the lab's image yourself, from any machine with the GitHub CLI and cosign installed. Replace the digest with the one shown on the package page.

$ gh attestation verify oci://ghcr.io/georgesmomo/devsecops-actions-lab@sha256:DIGEST --owner georgesmomo
$ cosign verify ghcr.io/georgesmomo/devsecops-actions-lab@sha256:DIGEST --certificate-identity-regexp "^https://github.com/georgesmomo/devsecops-actions-lab/" --certificate-oidc-issuer https://token.actions.githubusercontent.com

The six security rules of GitHub Actions

Script injection, seen up close

on: issues
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - run: echo "New issue: ${{ github.event.issue.title }}"

on: issues
permissions: {}
jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - env:
          TITLE: ${{ github.event.issue.title }}
        run: echo "New issue: $TITLE"

Actions, General

Runners

Environments

Secrets and variables

Rulesets (branch protection)

A GitHub App is a non-human identity that you install on an account or an organization. It receives events, acts with precise rights, and signs its actions as app-name[bot].

When Apps step in: real examples

Why companies use them

• Replace service accounts. A personal token belongs to a person: it breaks when they leave and uses a paid seat. An App has no password, no seat and no human owner.
• Real least privilege. Permissions per category (contents, issues, checks…), read or write, limited to the repositories where the App is installed, with one-hour tokens.
• Homemade required checks. Only GitHub Apps can create check runs, so an internal compliance tool becomes a required check in a ruleset.
• Automation across repositories. GITHUB_TOKEN only sees its own repository and triggers nothing. An App token can open a pull request in another repository and start its CI.
• Controlled bypass. A release bot can sit in a ruleset's bypass list to push a tag, without giving that right to any human.
• Traceability. Every action shows as app[bot] in the history and the audit log; the installation can be revoked in one click.

Constraints and pitfalls

GITHUB_TOKEN, GitHub App, OAuth App, PAT or OIDC?

Practice: create your own App for the lab

1. Avatar, Settings, Developer settings, GitHub Apps, New GitHub App.
2. Name: something unique such as yourname-lab-bot. Homepage: your fork's URL. Untick Webhook Active: the App will only serve as an identity in Actions, no server needed.
3. Repository permissions: Contents: Read and write, Pull requests: Read and write. Nothing else. Where can this be installed: Only on this account. Create.
4. On the App's page, note the Client ID, then Generate a private key (a .pem file downloads).
5. Menu Install App, your account, Only select repositories, your fork.
6. In your fork: variable APP_CLIENT_ID = the Client ID; secret APP_PRIVATE_KEY = the content of the .pem. Then delete the .pem from your disk.

jobs:
  bump:
    runs-on: ubuntu-latest
    permissions: {}                       # we do not use GITHUB_TOKEN at all
    steps:
      - id: app
        uses: actions/create-github-app-token@64ab729a6294000f5aa4a4bc0b73d1f32bc45510 # v3.3.0
        with:
          client-id: ${{ vars.APP_CLIENT_ID }}
          private-key: ${{ secrets.APP_PRIVATE_KEY }}
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with: { token: ${{ steps.app.outputs.token }}, persist-credentials: false }
      - env: { GH_TOKEN: ${{ steps.app.outputs.token }} }
        run: |
          git switch -c chore/bump-version
          sed -i 's/1.0.0/1.0.1/' app/app.py
          git -c user.name="yourname-lab-bot[bot]" commit -am "chore: bump 1.0.1"
          git push "https://x-access-token:${GH_TOKEN}@github.com/${GITHUB_REPOSITORY}" HEAD
          gh pr create --fill                # the CI starts on this pull request

AI appears in three places: the interface (chat, commit messages, review), agents that code on their own, and steps inside Actions workflows.

The Agents tab

Cloud agent settings

MCP servers for the agent

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp",
      "tools": ["get_issue_details"],
      "headers": { "Authorization": "Bearer $COPILOT_MCP_SENTRY_TOKEN" }
    }
  }
}

The tools list is an allow list: the agent can call only get_issue_details. Secrets prefixed COPILOT_MCP_ live in the repository's copilot environment.

AI inside workflows

on:
  pull_request:
    types: [opened, synchronize, reopened]
permissions:
  contents: read
  pull-requests: write
jobs:
  review:
    if: github.event.pull_request.head.repo.full_name == github.repository   # not on forks1
    steps:
      - name: Install Copilot CLI
        run: npm install -g @github/copilot
      - name: AI review
        id: ai
        uses: actions/ai-inference@2c43c91ae16266ca159d311430343c67a5ffa222 # v3
        with:
          prompt-file: .github/prompts/pr-review.prompt.yml2
          file_input: |
            diff: ./diff.txt
        env:
          COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_PAT }}
      - name: Comment on the pull request
        env:
          GH_TOKEN: ${{ github.token }}
          PR: ${{ github.event.pull_request.number }}
        run: gh pr comment "$PR" --body-file "${{ steps.ai.outputs.response-file }}"3

1. Fork pull requests get no secrets anyway, and running AI on a stranger's text is an injection risk: the job is skipped for them.
2. The prompt file tells the model that the diff is data to analyze and that it must not follow instructions found inside it.
3. The model has no write tool: it produces text, and the workflow decides what to do with it.

In the version the lab uses (v3), actions/ai-inference goes through the Copilot CLI, so it needs an account with a Copilot licence and a token stored as a secret. Without the COPILOT_PAT secret, the workflow only prints a warning. If you prefer Claude, the Marketplace action anthropics/claude-code-action with an ANTHROPIC_API_KEY secret plays the same role, triggered by @claude in a pull request or an issue.

GH-200 is GitHub's certification for GitHub Actions. The weights below come from the official study guide (outline revised in January 2026; passing score 700). Always check the current study guide before you book.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - &checkout { uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 }   # defines the anchor
      - run: pytest
  lint:
    runs-on: ubuntu-latest
    steps:
      - *checkout                                       # reuses the step
      - run: ruff check .
    services:                                           # a side container for the job
      db:
        image: postgres:17
        ports: ["5432:5432"]
        options: >-
          --health-cmd "pg_isready" --health-interval 5s

A revision plan that works

1. Read the lab's six workflows until you can explain every line out loud.
2. Redo the hands-on blocks of stations 5, 6 and 9 in your fork; break things and read the errors.
3. Learn the lists by heart: trigger types, contexts, status functions, permission scopes, secret precedence, retention defaults.
4. Take the final exam below until you score 80% or more, then take the official practice assessment.

Type a word (secret, runner, dependabot…) to filter the cards, then jump to the one you need.

Challenges to build next

Dotted words in the course open these definitions. Search them all here.

Continue the series

• GitLab CI/CD DevSecOps: the same lab rebuilt on GitLab.com, with a GitLab to GitHub dictionary.
• Kubernetes + Helm: what happens after the deploy step, from kubectl apply to Helm charts and debugging.

Official references

• GitHub Actions documentation
• GH-200 study guide
• Changelog: workflow lockfiles in public preview
• Changelog: automations with the Copilot cloud agent
• GitHub Copilot app
• actions/ai-inference
• Sigstore (cosign, Fulcio, Rekor) and SLSA

Found a mistake?

Open an issue on the lab repository. Screenshots were taken on the real repository in October 2026; GitHub's interface changes often, so labels may move slightly.