What is GitHub Actions and How Do Workflows Run?
Learn what GitHub Actions is, how workflow YAML, jobs, and runners work together, and how it differs from a standalone CI server.
Expected Interview Answer
GitHub Actions is GitHub’s native CI/CD platform where workflows are defined as YAML files in .github/workflows, triggered by repository events, and executed on GitHub-hosted or self-hosted runners without needing a separately maintained automation server.
A workflow file declares one or more jobs, each made of ordered steps that run shell commands or reusable, versioned Actions pulled from the marketplace or a private repo. Jobs run on runners — ephemeral GitHub-hosted VMs by default, or self-hosted machines for custom hardware or network access — and multiple jobs in one workflow run in parallel unless a `needs` dependency chains them sequentially. Triggers (`on:`) include pushes, pull requests, releases, schedules, and manual `workflow_dispatch`, so the same event model that drives collaboration also drives automation. Because workflows live in the same repo as the code, GitHub Actions has no separate server to patch or scale, and secrets, environments, and approval gates are managed directly in repository or organization settings.
- No separate CI server to install, patch, or scale
- Workflows live and version alongside the code they build
- Rich marketplace of reusable, versioned Actions
- Native integration with pull requests, releases, and repo events
AI Mentor Explanation
GitHub Actions is like a stadium’s own automated scoreboard-and-announcement system built directly into the ground, triggered instantly whenever a specific match event happens — a boundary, a wicket, an innings break — with no separate control room to build or wire up. Each trigger runs a predefined sequence of actions: update the score, play the sound, flash the replay. Because the system is built into the stadium itself, any ground using it gets the same automated behavior without installing extra equipment. A big final can even trigger a special manual announcement sequence on demand.
Step-by-Step Explanation
Step 1
Add a workflow file
Create a YAML file under .github/workflows defining `on:` triggers and one or more `jobs`.
Step 2
Define jobs and steps
Each job lists ordered steps that run shell commands or reusable Actions from the marketplace.
Step 3
Runner executes the job
GitHub dispatches the job to a hosted or self-hosted runner matching the specified `runs-on` label.
Step 4
Report status
Job results appear as checks on the commit/PR, gating merges via required status checks.
What Interviewer Expects
- Understanding of workflow YAML structure: on, jobs, steps
- Awareness of GitHub-hosted vs self-hosted runners
- Knowledge of parallel vs sequential job execution via `needs`
- Ability to explain how Actions differ from a traditional standalone CI server
Common Mistakes
- Forgetting that jobs run in parallel by default unless `needs` is set
- Hardcoding secrets in the workflow YAML instead of using repo secrets
- Not pinning third-party Action versions, risking supply-chain drift
- Confusing workflow-level `on:` triggers with job-level `if:` conditions
Best Answer (HR Friendly)
“GitHub Actions lets us define our build and deploy automation as YAML files that live right next to our code, triggered automatically by things like a push or a pull request. Because GitHub runs the infrastructure for us, we don’t have to install or maintain a separate CI server — we just describe what should happen and GitHub handles execution.”
Code Example
name: CI
on:
push:
branches: [main]
pull_request:
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: "20"
- run: npm ci
- run: npm testFollow-up Questions
- What is the difference between GitHub-hosted and self-hosted runners?
- How do you share data between jobs in the same workflow?
- How would you cache dependencies to speed up a workflow?
- What is a reusable workflow and when would you use one?
MCQ Practice
1. Where do GitHub Actions workflow files live in a repository?
Workflow YAML files must be placed under the .github/workflows directory for GitHub to detect and run them.
2. By default, how do multiple jobs in one workflow execute?
Jobs run in parallel by default; the `needs` keyword is required to force sequential execution.
3. What executes the steps defined in a GitHub Actions job?
Runners are the machines, hosted by GitHub or self-hosted, that actually execute a job's steps.
Flash Cards
What is GitHub Actions? — GitHub’s native CI/CD platform, with workflows defined as YAML triggered by repo events.
Where do workflow files live? — Under .github/workflows/ in the repository.
What executes a job? — A GitHub-hosted or self-hosted runner.
How do you force jobs to run in order? — Use the `needs` keyword to create a dependency between jobs.