Introduction to GitHub Actions: Easy Guide

If you've ever wished for a way to automate your code workflows on GitHub, GitHub Actions is the superhero you've been looking for. Whether you're pushing code, creating pull requests, or releasing new versions, GitHub Actions can handle it all with style and efficiency. Let's dive into the basics and get you started with some actionable tips!

What's GitHub Actions?

GitHub Actions is like having a personal assistant for your code. It allows you to automate, customize, and execute your software development workflows right in your GitHub repository. These workflows are defined in YAML files, which are easy to read and write. YAML stands for "YAML Ain't Markup Language," (clever huh) and it's perfect for creating data files that are both human-readable and machine-friendly.

Getting Started with Workflows

At the heart of GitHub Actions are workflows. Think of a workflow as a series of steps that GitHub will run in response to specific events, like a code push or a pull request. Here's a quick breakdown of the key attributes you'll use when defining a workflow:

• name: This is the name of your workflow. It's optional, but it's good practice to name it for clarity.
• on: This specifies the event that triggers the workflow. It’s mandatory. Events can be anything from a push, pull request, release, to GitHub webhooks.
• jobs: This section lists all the jobs your workflow will run. Each job has a unique identifier and includes:
  • runs-on: The type of machine required for the job.
  • steps: The specific actions and commands needed to run the job. Each step can access the file system but runs in its own process.

Creating Your First Workflow

To create a workflow, you'll need to add a YAML file to your repository under .github/workflows. Here’s a simple example to get you started:

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Run a one-line script
        run: echo "Hello, world!"

This example sets up a continuous integration (CI) workflow triggered on push and pull request events. It runs on an Ubuntu machine and includes two steps:

• Checkout Code: The actions/checkout@v2 action checks out your repository code so that the workflow can access it.
• Run a Script: A simple script that echoes "Hello, world!" to the console.

This basic setup gives you a taste of how GitHub Actions can automate tasks for you. From here, you can start adding more complex steps and actions to fit your project's needs.

Jobs in Your Workflow

A workflow without jobs is like a pizza without toppings—pretty useless! Each workflow needs at least one job, and jobs can run in parallel by default. However, if you need jobs to run sequentially, you can create dependencies using the needs keyword.

jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Job 1"

  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - run: echo "Job 2 depends on Job 1"

In this example, we have two jobs, job1 and job2 that will run on the latest version of Ubuntu available on GitHub Actions. Each has a single step that runs the command echo to print "Job 1" for the first job and "Job 2" for the second one to the console.
The needs keyword on the job2 indicates that it depends on the successful completion of job1. This creates a sequential dependency where job2 will only run after job1 finishes successfully.

Dependencies and Conditions

Sometimes, you need to add conditions to your workflows to control when and how they run for events like push or pull_request. For instance, if you only want your workflow to run on specific branches, you can add conditions using a YAML block. In that case, you don't use a value for the on keyword anymore. The event needs to be in its own YAML block and we add a branches conditional to list the branches we want to focus on, like so:

on:
  push:
    branches:
      - main
      - develop

Now that you understand how to create workflows, add jobs, and set dependencies and conditions, let's see how these concepts come together in a real-world example.

Real-World Example

Let’s say you have a Node.js project and you want to automate your testing process. Here’s how you could set up a GitHub Action to run your tests every time you push code:

name: Node.js CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x, 16.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm test

Let's break this down:

• name: The workflow is named "Node.js CI".
• on: The workflow is triggered by push and pull request events.
• jobs: One job named build.
• runs-on: Specifies the type of machine required for the job. Here, it’s set to ubuntu-latest, which means the job will run on the latest version of Ubuntu available on GitHub Actions.
• strategy: This uses a matrix to test multiple Node.js versions.
• steps: The workflow checks out the code, sets up Node.js, installs dependencies, and runs tests.

This is how you can combine various elements to create a powerful and automated CI workflow for your project.

Common Pitfalls and Solutions

Here are some pitfalls to be aware of:

• Incorrect YAML Indentation: YAML is sensitive to indentation. Make sure all nested elements are properly indented.
• Event Triggers Not Working: Double-check the spelling and formatting of event triggers. They must match GitHub's predefined events.
• Missing Permissions: Sometimes workflows fail due to insufficient permissions. Ensure that your workflow has the necessary permissions to access required resources.

Advanced Tips

• Using Secrets:

  jobs:
    deploy:
      runs-on: ubuntu-latest
      steps:
        - name: Checkout code
          uses: actions/checkout@v2
        - name: Deploy to production
          env:
            API_KEY: ${{ secrets.API_KEY }}
          run: ./deploy.sh

This ensures your sensitive data remains secure.

• Custom Actions: Create your own actions to encapsulate repeated tasks.
• Matrix Builds: Use matrix builds to test your code across multiple environments.

Stay tuned for more advanced tips in upcoming posts!

Workflow and Action Limitations

While GitHub Actions is incredibly powerful, there are some limitations to keep in mind:

• Each repository can have multiple workflows, but only 20 can run simultaneously.
• The free GitHub plan allows for 20 concurrent jobs per repository, with runtime limits of 6 hours per job.
• If your workflows interact with the GitHub API, you're limited to 1000 API requests per hour.

These limits might change, so always check the latest GitHub documentation for updates.

Wrapping Up

GitHub Actions is a game-changer for automating your development workflows. By mastering the basics of YAML and understanding how to structure your workflows and jobs, you can significantly boost your productivity. So, go ahead and start creating your custom workflows—your future self will thank you!

Comments

[Alex Pliutau]

Great write-up. We also have a bunch of articles on Github Actions in our Newsletter, check it out - packagemain.tech/p/github-actions-...

[vikas rathod]

Greater it's really usefull for beginners who want to get into it it's really helped me a lot to cleared a basic workflow understanding will wait for the further blogs on same

[Gervais Yao Amoah]

Glad to hear (read, haha) that !