Table of contents
  1. Getting started with GitHub
    1. Repositories, Branches, Push, Pull, Commit
    2. Understanding GitHub Actions
      1. For the Busy Readers
      2. Key Concepts in GitHub Actions
      3. Example Workflow
      4. Anatomy of a GitHub Workflow

Getting started with GitHub

Repositories, Branches, Push, Pull, Commit

  • Repositories
  • Branches
  • Push
  • Pull
  • Commits

Understanding GitHub Actions

In this article, I’ll explain the core concepts of GitHub Actions.

Further reading.

For the Busy Readers

GitHub Actions is a tool to automate code building and deployment tasks. With GitHub Actions, you create workflows. These workflows are YAML files inside the .github/workflows folder in your project. Workflows contain jobs, and jobs contain steps. Steps can be simple commands, scripts, or pre-built actions from the GitHub community.

Another explanation:

GitHub Actions is a GitHub feature that lets you run tasks when certain events happen in your code repository. You can use it to trigger any part of a CI/CD pipeline using webhooks on GitHub.

GitHub Actions offers over 13,000 pre-written and tested CI/CD workflows. You can also write your own workflows or customize existing ones using YAML files.

GitHub Actions is not just for CI/CD pipelines. Here are some other uses:

  • Running nightly builds in the master branch for testing.
  • Cleaning up old issues or bug reports.
  • Creating bots that respond to comments or commands on pull requests or issues.

In short, GitHub Actions is the GitHub feature that automates CI/CD and more.

GitHub Action is a tool. GitHub Actions Workflow is the output of the tool.

Key Concepts in GitHub Actions

Here are the key terms you will hear most of the time when dealing with GitHub Actions:

  1. Workflows: YAML files inside the .github/workflows folder.
  2. Jobs: Workflows contain jobs, which are sets of steps.
  3. Steps: Jobs are made up of steps that run commands, scripts, or actions.
  4. Runners: Servers that execute the jobs (can be GitHub-provided or self-hosted).

How It Works:

  1. Trigger: An event, like pushing code or creating a pull request, triggers the workflow.
  2. Workflow Activation: The specified workflow for that trigger starts running.
  3. Jobs Execution: Jobs within the workflow run, either independently or in sequence.
  4. Runners: Jobs use virtual machines provided by GitHub or self-hosted machines to run.

Example Workflow

You commit code to your repository. The workflow is triggered. Your code is built, tested, and deployed automatically.

GitHub provides virtual machines for Linux, Windows, and macOS.

Anatomy of a GitHub Workflow

A GitHub Actions workflow is written as a YAML file inside the .github/workflows directory of a project/repository. Each workflow is stored as a separate YAML file in your code repository.

This is how a typical workflow YAML file looks:

name: CI

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Build
      run: make build
  1. name: This workflow is named “CI” (Continuous Integration). You can name it anything you like.
  2. on: This workflow runs when there is a push to the main branch.
  3. jobs: This workflow has one job named build.
  4. runs-on: This job runs on an ubuntu-latest virtual machine.
  5. steps:
    • Checkout code: Uses actions/checkout@v3 to pull the code.
    • Build: Runs the make build command to build the project.

Table of contents