CHAPTER 07
GitHub Actions Basics
Updated: May 15, 2026
25 min read
# CHAPTER 7
GitHub Actions Basics
1. Introduction
In the early days of software, deploying a website meant a developer manually uploaded files via FTP to a server. Testing meant a developer manually clicking every button on the website to see if it broke. This manual process is slow, tedious, and highly prone to human error. Modern software engineering relies on CI/CD (Continuous Integration / Continuous Deployment). We use robots to automatically test our code and deploy it to the internet the exact second we click "Merge." In this chapter, we will introduce GitHub Actions, GitHub's built-in automation engine, and learn how to write workflows that trigger robots to do our heavy lifting.2. Learning Objectives
By the end of this chapter, you will be able to:- Define CI/CD (Continuous Integration / Continuous Deployment).
- Understand the architecture of GitHub Actions (Workflows, Jobs, Steps).
- Create a YAML workflow file.
-
Trigger an automated pipeline based on GitHub events (e.g.,
on: push).
- Understand how automated tests integrate with Pull Requests.
3. Beginner Explanation
Imagine a car manufacturing plant.- The Manual Way: A mechanic builds an engine, puts it in the car, and then drives the car around the block to see if it explodes. If it doesn't, they drive it to the dealership.
- The Automated Way (CI/CD): The mechanic puts the engine on a conveyor belt. The belt carries the engine into a massive testing machine. The machine automatically revs the engine to 10,000 RPM (Continuous Integration/Testing). If it survives, a robotic arm automatically drops the engine into the car and puts it on a truck to the dealership (Continuous Deployment).
GitHub Actions is the conveyor belt and the robotic arm. It automatically runs scripts every time you push code.
4. Anatomy of a GitHub Action
GitHub Actions are defined using YAML (.yml) files placed in a very specific hidden folder in your repository: .github/workflows/.
A workflow consists of three hierarchy levels:
-
1.
The Event (
on:): What triggers the robot? (e.g., "Every time someone pushes to themainbranch").
-
2.
The Job (
jobs:): What computer should the robot use? (e.g., "Spin up a temporary Ubuntu Linux server").
-
3.
The Steps (
steps:): The exact terminal commands the robot should type on that server.
5. Writing Your First Workflow
Let's look at a simple YAML file that automatically runs a test script whenever code is pushed.
yaml
6. Mini Project: Create a Simple CI Workflow
Let's build a workflow that just prints a greeting, proving the robot is listening.Step-by-Step Walkthrough:
- 1. In your local repository, create the required hidden folders:
mkdir -p .github/workflows
-
2.
Create a new YAML file:
touch .github/workflows/hello.yml
-
3.
Open
hello.ymland paste this simple code:
yaml
name: Say Hello
on: [push]
jobs:
greet:
runs-on: ubuntu-latest
steps:
-
run: echo "Hello! The robot successfully ran your code!"
`
-
4.
Commit and push:
`bash
git add .
git commit -m "Add GitHub Actions workflow"
git push origin main
`
-
5.
Go to your repository on
github.com. Click the Actions tab at the top. You will see your "Say Hello" workflow running! Click on it to see the terminal output of the robot printing your message.
7. Actions and Pull Requests (Quality Gates)
The true power of CI/CD is connecting Actions to Pull Requests.
If Developer A opens a PR, GitHub Actions instantly detects the PR and runs the automated testing workflow against Developer A's code.
-
If the tests Pass, GitHub puts a beautiful Green Checkmark
✓ on the PR.
-
If the tests Fail (the code is broken), GitHub puts a massive Red
X on the PR.
Repository admins can configure settings to *block* the "Merge" button entirely if the Red X is present, physically preventing broken code from ever reaching the main branch. This is a Quality Gate.
8. Best Practices
-
Use Community Actions: You don't have to write complex scripts from scratch. The GitHub Marketplace has thousands of pre-built actions (like
actions/checkout@v4 or aws-actions/configure-aws-credentials). You can simply plug these into your YAML file like Lego bricks to perform complex tasks like deploying to AWS or sending a Slack message.
9. Common Mistakes
-
YAML Indentation Errors: YAML relies entirely on spaces for formatting (like Python). It does NOT use tabs. If you accidentally use a Tab key, or if your indentation is off by a single space, the entire workflow will crash with a syntax error. Always use a code editor that supports YAML linting to catch these invisible errors.
10. Exercises
-
1.
What is the specific folder path required for GitHub Actions YAML files to be recognized by the server?
-
2.
Explain how a CI workflow acts as a "Quality Gate" during the Pull Request process.
11. FAQs
Q: Does GitHub Actions cost money?
A: For public (open-source) repositories, GitHub Actions is completely free and offers infinite computing minutes. For private corporate repositories, GitHub provides a generous free tier of a few thousand minutes per month, after which they charge per minute of computing time.
12. Summary
In Chapter 7, we graduated from manual execution to automated engineering. We introduced CI/CD, demonstrating how GitHub Actions replaces tedious manual testing and deployment with instant, robotic precision. By understanding the YAML architecture of Events, Jobs, and Steps, we learned how to provision temporary cloud servers to execute scripts the moment code is pushed. Most importantly, we connected these automated pipelines to our Pull Requests, establishing impenetrable Quality Gates that mathematically guarantee broken code cannot infect our production main` branch.