GitHub Actions: From Zero to Production(EP2)🚀

Episode 2 – Core Concepts: Workflows, Jobs, Steps & Actions

In Episode 1, we understood what CI/CD is and where GitHub Actions fits.
Now it’s time to understand the core building blocks of GitHub Actions.

Most confusion around GitHub Actions comes from not having a clear mental model of:

• workflows
• jobs
• steps
• actions

Once these click, everything else becomes easier.

---

The Big Picture (Mental Model)

Think of GitHub Actions like this:

Workflow
  └── Job(s)
        └── Step(s)
              ├── run (your command)
              └── uses (reusable action)

Let’s break this down one by one.

---

1️⃣ What is a Workflow?

A workflow is the top-level automation.

It:

• lives inside your repository
• is written in YAML
• defines when and what should run

📁 Location:

.github/workflows/ci.yml

Example:

name: CI Pipeline
on: push

This means:

“Run this pipeline when code is pushed”

---

2️⃣ What is a Job?

A job is a logical stage inside a workflow.

Each job:

• runs on a machine (runner)
• has its own environment
• contains steps
• runs in parallel by default

Example:

jobs:
  build:
    runs-on: ubuntu-latest

Here:

• build is the job name
• ubuntu-latest is the runner (machine)

---

3️⃣ What is a Step?

A step is a single task inside a job.

Steps:

• run in order
• share the same machine
• can access files created by previous steps

Example:

steps:
  - run: npm install
  - run: npm test

Each run is a step.

---

4️⃣ What is an Action?

An action is a reusable block of logic written by GitHub or the community.

Instead of writing everything yourself, you reuse actions.

Example:

- uses: actions/checkout@v4

This action:

• clones your repository into the runner
• handles authentication
• works for private repos
• supports PRs, branches, and commits

Without it, your runner has no code.

---

5️⃣ run vs uses (Very Important)

run

• Executes shell commands
• You write the logic

- run: npm ci

uses

• Executes reusable logic
• Someone else wrote the code

- uses: actions/setup-node@v4

👉 Rule of thumb:

• Project-specific logic → run
• Reusable setup logic → uses

---

6️⃣ A Complete Example (Everything Together)

name: CI

on: pull_request

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 18

      - run: npm ci
      - run: npm test

What’s happening here:

• Workflow runs on PR
• One job (test)
• Runs on Ubuntu
• Uses actions to checkout code & setup Node
• Runs project commands

This is a clean CI pipeline.

---

7️⃣ Common Beginner Mistakes

❌ Forgetting actions/checkout
❌ Mixing CI & deployment logic
❌ Writing huge bash scripts inside workflows
❌ Not naming steps clearly

Good workflows are:

• readable
• predictable
• boring (in a good way)

---

Final Mental Model (Lock This In)

Workflow → automation
Job      → stage
Step     → task
Action   → reusable logic
Runner   → machine

If this model is clear, GitHub Actions will stop feeling magical and start feeling logical.

---

What’s Next?

👉 Episode 3:
Workflow Syntax & Events – push, pull_request, cron & manual triggers

We’ll finally answer:

• when does a workflow run?
• how to control it precisely?

Follow along if you’re learning GitHub Actions step by step 🚀

---

Thanks for reading!
See you in the next episode 👋