DEV Community

Cover image for Git Hub Workflow - part 1
asanka rajanayaka
asanka rajanayaka

Posted on

Git Hub Workflow - part 1

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

  1. Trigger (when to run)
  2. Jobs (what machines to use)
  3. 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
Enter fullscreen mode Exit fullscreen mode

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 the stepssection 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 ]
Enter fullscreen mode Exit fullscreen mode
  • pull_request: Used to validate code before it is merged into the main branch
on:
  pull_request:
    branches: [ main ]
Enter fullscreen mode Exit fullscreen mode
  • workflow_dispatch(manual) : Adds a button in the GitHub UI to allow manual runs
on:
  workflow_dispatch:
Enter fullscreen mode Exit fullscreen mode
  • schedule(cron) : Runs at specific times (e.g., nightly reports).
on:
  schedule:
    - cron: "0 2 * * *"
Enter fullscreen mode Exit fullscreen mode

Also there is option if we need to filter specific files change to Triggers the workflow, leading to faster pipelines.

on:
  push:
    paths:
      - "src/**"
Enter fullscreen mode Exit fullscreen mode

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:
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode
  • 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)