Automate Your Code with GitHub Actions #1: Fundamentals of GitHub Actions

GitHub Actions is a powerful automation platform integrated directly into GitHub, enabling developers to create workflows that respond to events within their repositories.

Most often the use case of CI/CD is associated with GitHub Actions, but it can be used for much more than that. For advanced software developers, GitHub Actions offers a flexible, event-driven framework to automate complex tasks, streamline development processes, and enforce best practices across teams.

Who is Bas Steins?

Bas is a software developer and technology trainer based in the triangle between the Netherlands, Germany, and Belgium. For almost two decades, he has been helping people turn their ideas into software and helping other developers write better code. This series is based on his mini-guide "Automate Your Code with GitHub Actions".

What Is GitHub Actions?

At its core, GitHub Actions is an automation platform that enables developers to define workflows—sequences of tasks—triggered by specific events in a GitHub repository. These events can range from code pushes and pull requests to issue comments, scheduled times, or even external triggers through webhooks. Each workflow is composed of jobs, which run in parallel or sequentially, and each job consists of steps that execute specific commands or reusable actions.

For advanced developers, the true power of GitHub Actions lies in its deep integration with GitHub's ecosystem. Unlike standalone CI/CD tools (like Jenkins), GitHub Actions is inherently tied to repository events, enabling highly contextual automation. This means workflows can be tailored to respond to precise conditions, such as a pull request from a specific branch or a comment containing a particular keyword. Additionally, GitHub Actions supports both GitHub-hosted and self-hosted runners, providing flexibility for organizations with unique infrastructure needs or compliance requirements.

However, it's essential to recognize that GitHub Actions isn't a one-size-fits-all solution. While it excels in scenarios tightly coupled with GitHub's features, it may not fully replace more mature CI/CD platforms such as Jenkins or CircleCI for certain use cases—particularly those requiring extensive plugin ecosystems or complex orchestration across multiple repositories.

Pricing

GitHub Actions comes with a generous free tier that allows you to run up to 2,000 minutes per month on the GitHub Free plan. If you need more minutes, you can upgrade to a paid plan, such as GitHub Pro or GitHub Team, which offer 3,000 minutes per month. For larger organizations, GitHub Enterprise Cloud provides 50,000 minutes per month.

As of the date of writing, these are the current pricing tiers. Please check this link for the most up-to-date pricing.

The free minutes are based on a Linux virtual machine with 2 Cores and 7 GB of RAM. If you need more resources, you can choose from different virtual machine configurations, such as Windows, macOS, or ARM64. Each configuration has a different pricing model based on the resources provided.

In general, a Windows virtual machine costs twice as much as a Linux virtual machine, while a macOS virtual machine costs ten times as much as a Linux virtual machine. The ARM64 virtual machine is currently in public preview and has a different pricing model.

Our First Workflow

A workflow in GitHub Actions is defined using a YAML file stored in the .github/workflows directory of your repository. Yes, that's a directory and that means you can define multiple workflows for a single repository.

Let's look at an example and break it down:

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '14'
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

  deploy:
    runs-on: ubuntu-latest
    needs: build-and-test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        run: echo "Deploying to production"  # Replace with actual deployment command

Explanation

The workflow above is a CI/CD pipeline that builds and tests a project on pull requests and deploys it to production on pushes to the main branch. Here's a breakdown of the key components:

• Triggers: The workflow runs on both push and pull_request events for the main branch.
• Jobs:
  • build-and-test: This job checks out the code, sets up Node.js, installs dependencies, and runs tests. It runs on both pushes and pull requests.
  • deploy: This job depends on the successful completion of build-and-test (via needs: build-and-test) and only runs on pushes to the main branch (enforced by the if condition). It simulates a deployment step.
• Conditional Execution: The if statement in the deploy job ensures that deployment only occurs when code is pushed directly to main, not on pull requests.
• Steps: Each job consists of a series of steps that execute commands or actions. In this example, we use the actions/checkout action to fetch the code, and a placeholder command to simulate deployment.
• Actions: The uses keyword is used to invoke reusable actions from the GitHub Marketplace. In this case, we use the actions/checkout action to fetch the code.
• Runners: The runs-on keyword specifies the runner environment for each job. In this case, both jobs run on an ubuntu-latest virtual machine.

To put it simple, a workflow is triggered by an event and consists of one or more jobs that run on runners. Each job contains a series of steps that execute commands or actions.

In the next article, we will dive deeper into each component. See you there!