Skip to main content
GitHub Actions
CHAPTER 02

Understanding GitHub Workflows

Updated: May 15, 2026
20 min read

# CHAPTER 2

Understanding GitHub Workflows

1. Introduction

In Chapter 1, we saw GitHub Actions print "Hello World" to a console. But how did GitHub know *when* to print it? How did it know *where* to run the command? To build complex automation, you must understand the core architecture of a GitHub Action. The entire system is built around a hierarchy of five specific components: Workflows, Events, Jobs, Steps, and Runners. In this chapter, we will dissect this architecture and understand how these pieces fit together to form a CI/CD pipeline.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the five core components of GitHub Actions.
  • Explain how "Events" trigger automation.
  • Understand the hierarchical relationship between Jobs and Steps.
  • Describe what a "Runner" is.
  • Conceptualize how multiple jobs execute in parallel.

3. Beginner-Friendly Explanation

Imagine a professional restaurant kitchen.
  1. 1. The Event (Trigger): A waiter hands a ticket to the kitchen: "Table 4 wants a burger." This triggers the whole process.
  1. 2. The Workflow (The Process): The master plan for fulfilling the order. "We need to cook the meat and prepare the salad."
  1. 3. The Jobs (The Stations):
  • *Job 1:* The Grill Station (Cooks the meat).
  • *Job 2:* The Prep Station (Chops the salad).
*(Notice that the Grill and Prep stations can work at the exact same time! This is called parallel execution).*
  1. 4. The Steps (The Tasks): At the Prep Station, the chef must follow steps sequentially: Step 1: Wash lettuce. Step 2: Chop tomatoes. Step 3: Add dressing.
  1. 5. The Runner (The Chef/Kitchen): The physical person and equipment actually doing the work.

4. The Five Core Components

Let's map the restaurant analogy directly to GitHub Actions:
  1. 1. Events (on:): A specific activity that triggers the workflow. The most common is push (someone uploads code), but it can also be pull_request, schedule (like a cron job), or even issues (when someone opens a bug report).
  1. 2. Workflows: The automated procedure added to your repository. Defined by a YAML file inside .github/workflows/. A repository can have multiple workflows (e.g., one for testing, one for deploying).
  1. 3. Jobs (jobs:): A set of steps that execute on the *same runner*. By default, if a workflow has multiple jobs, they run in parallel (at the same time) on completely different cloud servers to save time.
  1. 4. Steps (steps:): Individual tasks within a job. Steps run sequentially (one after the other). A step can be a simple shell command (like echo "Hello") or a pre-built Action downloaded from the Marketplace.
  1. 5. Runners (runs-on:): A server provided by GitHub (or hosted by you) that runs your workflow. When a workflow is triggered, GitHub provisions a brand new, clean Virtual Machine, runs your job, and then destroys the machine.

5. Visualizing the Hierarchy

Here is how the hierarchy looks in code:
yaml
1234567891011 
name: CI Process (This is the WORKFLOW)
on: push (This is the EVENT)

jobs:
  test-code: (This is a JOB)
    runs-on: ubuntu-latest (This is the RUNNER)
    steps:
      - name: Step 1 (This is a STEP)
        run: echo "Doing something"
      - name: Step 2 (This is a STEP)
        run: echo "Doing something else"

6. Mini Project: Create an Automated Workflow on Push Event

Let's create a workflow that demonstrates the hierarchy and runs two jobs at the same time.

Step-by-Step Walkthrough:

  1. 1. In your GitHub repository, create or edit .github/workflows/main.yml.
  1. 2. Paste the following YAML code:

yaml
12345678910111213141516171819 
name: Parallel Jobs Demo
on: [push]

jobs:
  # JOB 1: Backend Testing
  backend-tests:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Starting backend tests..."
      - run: sleep 10 # Simulating a 10-second test
      - run: echo "Backend tests passed!"

  # JOB 2: Frontend Testing
  frontend-tests:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Starting frontend tests..."
      - run: sleep 10 # Simulating a 10-second test
      - run: echo "Frontend tests passed!"
  1. 3. Commit the code.
  1. 4. Go to the Actions tab. Click on the running workflow.
  1. 5. Observation: You will see both backend-tests and frontend-tests running simultaneously! Even though each job takes 10 seconds, the entire workflow only takes 10 seconds total, because GitHub spun up two separate Ubuntu servers (Runners) to do the work in parallel.

7. Real-World Scenarios

A development team had a massive test suite. Testing the database took 20 minutes, and testing the user interface took 20 minutes. In their old system, these ran sequentially (one after the other), meaning developers had to wait 40 minutes for feedback. By migrating to GitHub Actions, they split the tests into two separate jobs. GitHub executed them in parallel on two separate runners. The total feedback time dropped to 20 minutes, doubling the team's productivity.

8. Best Practices

  • Keep Steps Small: Do not put a massive 50-line Bash script inside a single run step. Break it out into multiple steps with clear name attributes. If the workflow fails, you want GitHub to highlight exactly which tiny step broke, rather than forcing you to read through a massive wall of text.

9. Security Recommendations

  • Beware of Public Pull Requests: If you maintain an open-source public repository, be very careful about triggering workflows on pullrequest. A malicious user could submit a Pull Request containing code designed to mine cryptocurrency using your free GitHub Action minutes! (GitHub has built-in protections for this, but awareness is key).

10. Troubleshooting Tips

  • Sequential Jobs: What if Job 2 *needs* Job 1 to finish first? (e.g., You shouldn't "Deploy" until "Test" passes). By default, they run at the same time. To fix this, use the needs keyword. Example: needs: backend-tests. We will cover this heavily in deployment chapters.

11. Exercises

  1. 1. If a workflow contains two jobs, and each job contains three steps, which parts run in parallel and which parts run sequentially?
  1. 2. What is the operational benefit of GitHub destroying the Runner (the Virtual Machine) immediately after your job finishes?

12. FAQs

Q: Can a workflow be triggered by clicking a button manually, rather than pushing code? A: Yes! You can use the event trigger on: workflowdispatch. This creates a "Run Workflow" button in the GitHub UI, allowing you to trigger deployments manually.

13. Interview Questions

  • Q: Explain the architectural hierarchy of GitHub Actions. How do Workflows, Jobs, and Steps relate to one another?
  • Q: A developer complains that their CI pipeline takes too long because it compiles the application, runs unit tests, and runs security scans sequentially. How would you restructure the YAML file to optimize execution time?

14. Summary

In Chapter 2, we decoded the architectural blueprint of GitHub Actions. We learned that automation is initiated by specific Events. Once triggered, the Workflow assigns discrete Jobs to temporary cloud servers called Runners. We discovered the immense power of parallel execution: because Jobs run independently, we can drastically reduce our build times by running multiple tasks simultaneously. Within those jobs, we define precise, sequential Steps to achieve our technical goals.

15. Next Chapter Recommendation

We've looked at the structure, but writing YAML requires precise syntax. A single misplaced space can crash the entire system. Proceed to Chapter 3: GitHub Actions YAML Syntax.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Introduction to GitHub Actions and CI/CD
Next Chapter GitHub Actions YAML Syntax

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5

🧪 Related Labs 1