DEV Community

Cover image for GitHub Actions: From Zero to Production(EP4)🚀
Vishwark
Vishwark

Posted on

GitHub Actions: From Zero to Production(EP4)🚀

#githubactions #frontend #github #cicd

Episode 4 – Runners, Actions & the Marketplace

In the previous episodes, we learned:

  • what CI/CD is
  • how workflows, jobs, and steps are structured
  • when workflows run using events and triggers

Now let’s answer a question every beginner (and many experienced devs) ask:

Where does my GitHub Actions code actually run?

And closely related:

What really happens when I use uses:?

The Missing Piece: Execution

Until now, we focused on structure and triggers.
This episode is about execution.

In GitHub Actions, execution depends on three things:

  1. Runners – the machine that runs your job
  2. Actions – reusable logic blocks
  3. Marketplace – where most actions come from

1️⃣ What is a Runner?

A runner is simply a machine that executes your jobs.

Every job must declare:

runs-on: ubuntu-latest
Enter fullscreen mode Exit fullscreen mode

This answers:

“Which machine should run this job?”

Mental model:

Workflow → Job → Runner → Steps
Enter fullscreen mode Exit fullscreen mode

2️⃣ GitHub-Hosted Runners (Most Common)

GitHub provides ready-to-use virtual machines.

Example:

runs-on: ubuntu-latest
Enter fullscreen mode Exit fullscreen mode

Available options:

  • ubuntu-latest
  • windows-latest
  • macos-latest

What happens internally?

  1. GitHub spins up a fresh VM
  2. Your job runs
  3. VM is destroyed after completion

This means:

  • no leftover files
  • no shared state
  • clean environment every run

What’s preinstalled on GitHub-hosted runners?

Most common tools are already there:

  • Git
  • Node.js, Python, Java
  • Docker
  • Build tools

That’s why CI setup feels “magical” at first.

3️⃣ Self-Hosted Runners (When You Need More Control)

A self-hosted runner is a machine you own and manage.

Examples:

  • Cloud VM (EC2, GCP, Azure)
  • Company server
  • On-prem machine

Usage:

runs-on: self-hosted
Enter fullscreen mode Exit fullscreen mode

Or with labels:

runs-on: [self-hosted, linux, prod]
Enter fullscreen mode Exit fullscreen mode

When do teams use self-hosted runners?

  • Need access to internal network
  • Custom hardware or licensed software
  • Faster builds for large monorepos
  • Enterprise deployments

For most projects, GitHub-hosted runners are enough.

4️⃣ What is an Action?

An action is a reusable block of logic.

Instead of writing everything yourself, you reuse actions created by:

  • GitHub
  • the community
  • your own team

Example:

- uses: actions/checkout@v4
Enter fullscreen mode Exit fullscreen mode

This single line:

  • clones your repo
  • authenticates securely
  • supports PRs & private repos

Without it, the runner has no code.

5️⃣ run vs uses (Important Difference)

run

Runs shell commands you write.

- run: npm ci
Enter fullscreen mode Exit fullscreen mode

uses

Executes reusable logic written by others.

- uses: actions/setup-node@v4
Enter fullscreen mode Exit fullscreen mode

Rule of thumb:

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

6️⃣ The GitHub Actions Marketplace

The Marketplace is a catalog of actions.

Think of it as:

  • npm registry → but for CI logic

Popular actions:

  • checkout code
  • setup languages
  • cache dependencies
  • upload artifacts
  • deploy apps

Most workflows use multiple marketplace actions.

7️⃣ Types of Actions (Under the Hood)

Actions can be implemented in different ways:

🔹 JavaScript actions

  • Written in Node.js
  • Fast
  • Most common

🔹 Docker actions

  • Run inside a container
  • Full environment control
  • Slower startup

🔹 Composite actions

  • Multiple steps grouped together
  • Great for reuse inside an org

You’ll mostly consume actions, not build them (at least initially).

8️⃣ A Complete Example (Everything Together) 

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - run: npm ci
      - run: npm run build
Enter fullscreen mode Exit fullscreen mode

What’s happening:

  • Job runs on GitHub-hosted Ubuntu
  • Actions handle setup
  • Commands handle project logic

This separation keeps workflows clean and readable.

Common Mistakes 🚨

❌ Assuming runners persist data
❌ Writing long scripts instead of reusable actions
❌ Using untrusted marketplace actions
❌ Not pinning action versions

Good workflows are:

  • explicit
  • boring
  • predictable

Final Mental Model (Lock This In) 

Runner   → where code runs
Action   → reusable logic
run      → your command
Marketplace → action library
Enter fullscreen mode Exit fullscreen mode

Once this is clear, GitHub Actions becomes much easier to reason about.

What’s Next?

👉 Episode 5:
Secrets, Variables & Environments – Handling Credentials Safely

This is where we talk about:

  • secrets vs variables
  • repo vs environment secrets
  • production safety

Follow the series to move from basics to production-ready pipelines 🚀

Thanks for reading!
See you in the next episode 👋

Top comments (0)