In the world of modern software engineering, manual deployments and local testing are relics of the past. If you want to build robust, scalable applications, you need to master GitHub Workflows.
Today, we’re breaking down everything you need to know to transform your repository into an automated powerhouse.
what is a github Workflow?
A GitHub Workflow is an automated pipeline defined in a YAML file. It lives right inside your repository and handles the heavy lifting of building, testing, and deploying your code.
The Essentials:
Location: Stored in the
.github/workflows/directory.Triggers: Activated by events like a push, pull_request, or even a schedule
Environment: Runs on GitHub-hosted virtual machines (Ubuntu, Windows, macOS) or your own self-hosted runners.
How It Makes CI/CD Easy
Continuous Integration (CI) is simplified because there are no servers to manage. Everything is defined in a simple, human-readable YAML file.
Continuous Deployment (CD) becomes seamless because your code and your deployment logic live in the same place. With built-in Secret Management, you can deploy to production securely without ever hard-coding a password.
Main Part Of Workflow
- Trigger (when to run)
- Jobs (what machines to use)
- Steps (what to execute)
This is a minimum GitHub workflow example.
name: CI Pipeline
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
what is GitHub action?
A GitHub Action is a reusable piece of automation logic designed to perform a specific, isolated task within a GitHub workflow. Think of it as a modular "building block" for your automation pipeline
Key Points:
Reusable Unit of Work: Once an action is created, it can be used across multiple different workflows and projects.
Used Inside Workflow Steps: Actions are called within thestepssection of a job.
Created by GitHub or the Community: You can use official actions from GitHub or leverage thousands of actions shared by the developer community.
Stored in a Repo: Every action lives in a repository, which allows for version control (eg @v4).
Why Do Actions Exist?
The primary purpose of Actions is to eliminate redundancy. Instead of writing long, complex shell scripts repeatedly across different projects to handle common tasks, you use an Action.
Eg: Checking out Code Instead of manually writing a script to perform a git clone, you use the official checkout action:
- uses: actions/checkout@v4
Lets deep dive into few main key aspect we commonly used with github workflow.
1. name
This provides a human-readable name for your workflow. It is what you will see in the "Actions" tab of your GitHub repository.
name: CI Pipeline
2. on(Trigger)
Defines when the workflow should run. You can use single triggers or combine multiple triggers together.
Most common triggers:
push: Runs when code is pushed to a specific branch.
on:
push:
branches: [ main ]
pull_request: Used to validate code before it is merged into the main branch
on:
pull_request:
branches: [ main ]
workflow_dispatch(manual) : Adds a button in the GitHub UI to allow manual runs
on:
workflow_dispatch:
schedule(cron) : Runs at specific times (e.g., nightly reports).
on:
schedule:
- cron: "0 2 * * *"
Also there is option if we need to filter specific files change to Triggers the workflow, leading to faster pipelines.
on:
push:
paths:
- "src/**"
Multiple triggers
If we need to run a workflow by combining more than one trigger, we can use multiple triggers
This workflow will run for Push, PR and Manual run.
on:
push:
branches: [ main ]
pull_request:
workflow_dispatch:
3.jobs
A job is a set of steps that execute on the same runner (virtual machine). A workflow can contain one or many jobs
Basic structure
You define a job ID (like build) and the machine type (runs-on).
build → job name (ID)
runs-on → runner (machine)
jobs:
build:
runs-on: ubuntu-latest
What Contain in a job?
It contains a set of steps. (In the next topic, we will discuss the steps.)
All steps inside a single job run one after another and share the same filesystem. If one step fails, the whole job fails.
jobs:
test:
runs-on: ubuntu-latest
steps:
- run: echo "Hello CI"
The run behavior of jobs can be divided into two parts for comparison.
1.Multiple jobs
This is a Parallel Executio. By default, multiple jobs run at the same time to speed up CI.
Eg: lint and test ran in parallel
jobs:
lint:
runs-on: ubuntu-latest
test:
runs-on: ubuntu-latest
2.Job dependencies
The needs is used to define job dependencies. It ensures that one job waits for another to complete before running.
Eg: deploy ran only if build succeeded
jobs:
build:
runs-on: ubuntu-latest
deploy:
runs-on: ubuntu-latest
needs: build
4.steps
A step is a single action or command execute inside a job.
Steps run one by one, in order.
There are 2 type of steps.
run(Shell Commands)
Used for CLI commands, scripts, or running tests
- run: npm install
- run: npm test
You can also use multi-line:
Lets if need to performs two distinct actions of npm install && npm run build. Installing dependencies and then executing the project's build script.
- run: |
npm install
npm run build
uses(GitHub Action)
Used for reusable logic, setting up tools and Third-party integrations. This avoids manual scripting for common tasks like checking out code.
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
Look this Basic Full Example of Steps
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm test
In my upcoming blog, We’ll dive deeper into some of the most powerful workflow concepts. We’ll explore Runners, environment variables, secrets management, strategies, and conditional execution.