Gnu Group Learning AcademyGnu Group ↗
CI/CD Fundamentals · Module 02 of 12

Pipeline as code with GitHub Actions

Define workflows in version-controlled YAML and understand events, workflows, jobs and steps.

Learning objectives

By the end of this module, you should be able to:

  • Locate GitHub Actions workflow files correctly.
  • Explain the relationship between events, workflows, jobs and steps.
  • Create a minimal validation workflow with least-privilege token permissions.

Workflow files are versioned with the repository

GitHub Actions workflow definitions live under .github/workflows and use YAML. Keeping pipeline logic beside source code makes changes reviewable and traceable with the application.

Events start workflows

The on key defines triggers such as push, pull_request or workflow_dispatch. Trigger choice is part of the security model because untrusted code can arrive through pull requests.

Jobs contain ordered steps

Jobs run on runners and are parallel by default unless dependencies are expressed with needs. Steps in a job run sequentially and can execute shell commands or reusable actions.

Worked examples

See the idea in practice.

Minimal pull-request validation

name: validate
on:
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: echo validate
  • The workflow is triggered by pull requests.
  • The token is explicitly limited to contents: read for this simple job.
Hands-on lab

Lab — Write a workflow as code

Goal: Create a syntactically simple GitHub Actions workflow that documents trigger, permissions, runner and steps.

Before you start

  • No GitHub token is required for the local validation.
  • Publishing the repository to GitHub is optional for observing an actual hosted run.
STEP 1

Create workflow directory

mkdir -p ~/gnu-cicd-labs/module02/.github/workflows && cd ~/gnu-cicd-labs/module02
STEP 2

Write validation workflow

cat > .github/workflows/validate.yml <<'EOF'
name: validate
on:
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: printf 'validate\n'
EOF
STEP 3

Inspect the pipeline contract

grep -E '^(name:|on:|permissions:|jobs:)' .github/workflows/validate.yml
STEP 4

Check required keys

grep -q 'pull_request:' .github/workflows/validate.yml && grep -q 'contents: read' .github/workflows/validate.yml

Verify

  • The file is under .github/workflows.
  • The workflow defines a pull_request trigger, a job, a runner and explicit contents: read permission.

Expected outcome

  • Pipeline configuration is reviewable source code rather than hidden UI configuration.

If it fails

  • YAML indentation is significant; use spaces consistently.
  • If GitHub reports an invalid workflow, open the workflow file in the Actions UI to inspect the parser error and line number.
Real-world connection

Pipeline changes should receive code review because they can change build, credential and deployment behavior.

Avoid these traps

Common mistakes

  • Putting workflows outside .github/workflows.
  • Giving GITHUB_TOKEN broad write permissions by default.
  • Using an event without considering whether its input can contain untrusted code.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1Where do GitHub Actions workflow files live?

In the repository's .github/workflows directory.

2What does runs-on select?

The runner environment used for the job.

3Why put pipeline logic in version control?

So automation changes are traceable, reviewable and reproducible with the source.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Attempt the core lab and knowledge checks before marking the module complete.