GitHub Actions fundamentals

Five classes ago your infrastructure became text in a repository. That bought review, history, and repeatability — but somebody still has to run the linter, run the what-if, and run the deploy, and humans forget, skip steps at 5pm on a Friday, and go on holiday. GitHub Actions is GitHub's built-in automation: you describe, in a YAML file that lives in the repository at .github/workflows/, what should run and when — and from then on it runs every time, identically, whether it is the first pull request of the morning or the fortieth.

Workflow

An automated process defined in a YAML file in .github/workflows/, started by an event, made of one or more jobs, each a sequence of steps run on a fresh machine called a runner.

One small, real workflow contains every concept in this class. This is Campux's first — it validates the Bicep from Class Twenty on every pull request:

# .github/workflows/validate.yml
name: Validate infrastructure

on:
  pull_request:
    branches: [ main ]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Bicep (fails on errors)
        run: az bicep build --file infra/main.bicep

on — the trigger

The event that starts the workflow: a push, a pull_request, a schedule (cron), or workflow_dispatch — a button a human presses.

job

A named unit of work. Multiple jobs run in parallel by default, each on its own machine; needs: chains them in order.

runner

The machine a job runs on. ubuntu-latest is a fresh virtual machine GitHub provides, used once and destroyed.¹

step

One command (run:) or one reusable action (uses:). Steps in a job run in order and share the runner's filesystem.

action

A packaged, reusable step from the marketplace — actions/checkout@v4 clones your repository so later steps can see the code. You will use ten of these before you ever write one.

Read the flow once, top to bottom: a pull request against main fires the trigger; GitHub boots a fresh Ubuntu machine; the machine checks out the branch and compiles the Bicep; and the result — green tick or red cross — lands on the pull request itself. Wire that into the Class Eighteen branch protection rule that requires status checks, and broken infrastructure code physically cannot merge. That is the whole trick, and every pipeline you will ever build is this pattern with more steps.

Workflows need to know things about the run they are in — who opened the pull request, which branch, what secret to use. That information arrives through contexts, read with the ${{ … }} expression syntax. You need surprisingly few of them:

# the contexts you will actually use
steps:
  - name: Show the facts of the run
    run: |
      echo "Actor:  ${{ github.actor }}"
      echo "Branch: ${{ github.ref_name }}"
      echo "Event:  ${{ github.event_name }}"

  - name: Deploy — but only from main
    if: github.ref_name == 'main'
    run: ./deploy.sh
  # secrets.NAME and vars.NAME — covered next section

Three ideas cover most working uses. The github context holds the facts of the event — actor, branch, event name — so a single workflow can behave differently per situation. The if: key gates a step or a whole job on an expression, which is how "run the deploy only on main" is written. And secrets and vars are contexts too — pipes through which configuration reaches the run without living in the file. When a workflow misbehaves, the first debugging move is almost always printing the github context values: half of all "why did this not run?" mysteries are an event name or branch ref that is not what you assumed.

The moment a workflow does anything real — deploys, publishes, talks to Azure — it needs configuration, and some of that configuration is sensitive. GitHub gives you three containers for it, and choosing the wrong one is a security decision made by accident.

Environments are the one of the three that beginners skip and professionals lean on. The same workflow file can deploy to nonprod on every merge and to production only after a named person clicks approve — not because the YAML branches cleverly, but because each environment carries its own credentials and its own gate. The production secret does not exist for a job that has not passed production's protection rules. That is the same design instinct as Class Eight's RBAC: do not trust the process to behave; scope what it can reach.

One warning that will save you an incident: secret masking is a courtesy, not a guarantee. GitHub scrubs exact matches of secret values from logs, but a secret that gets transformed — encoded, split, interpolated into a URL — walks straight past the filter.² The rule is not "masking will catch it"; the rule is that no step should ever print a secret, and a reviewer should treat an echo anywhere near secrets. as a finding.

Workflows accumulate duplication fast: the same steps against three environments, the same validation in four repositories. Actions has two answers. A matrix runs one job definition many times with different inputs, in parallel:

# one job definition, three parallel runs
jobs:
  validate:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        environment: [ dev, test, prod ]
    steps:
      - uses: actions/checkout@v4
      - name: What-if against ${{ matrix.environment }}
        run: |
          az deployment group what-if \
            --resource-group rg-campux-${{ matrix.environment }} \
            --template-file infra/main.bicep

And for duplication across repositories, a reusable workflow — a workflow whose trigger is workflow_call — lets other workflows invoke it like a function, inputs and secrets passed explicitly. The judgement call mirrors Class Twenty's modules exactly: extract when the same steps live in three places, not before. A matrix that multiplies a broken job produces three failures instead of one insight, and a reusable workflow extracted too early becomes a dependency every team is afraid to touch. Compose small, tested pieces — the lesson has not changed since Bicep, only the file format has.

Here is the fact that separates teams that take CI seriously from teams that have incidents about it: the workflow file can read your secrets and deploy to your production. That sentence has an implication — whatever reviews production changes must review this file with the same care. A one-line edit to a workflow can widen a trigger, print a credential, skip a validation step, or point a deploy at the wrong subscription, and it will look like harmless YAML in a diff full of real code.

The pipeline is production code.

Review a workflow diff with four questions. Trigger: did on: change — does anything new start this workflow, and could an outsider's pull request start it? Permissions: what can the job now reach — new secrets, a new environment, a wider token? Steps: is anything echoed, uploaded, or sent somewhere that was not before? Gates: did a needs:, an if:, or an environment protection quietly disappear? Four questions, thirty seconds each — and they catch the class of bug that a thousand green runs never will, because the run only proves the workflow did what it says, not that it says the right thing.