Understanding the basics of GitHub Actions

Overview

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment processes. For example, you can create workflows that build and test every pull request to your repository. Once it’s merged you can deploy it.

But it goes beyond that and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

But first, before running the workflow we need some compute resources. These are called runners. GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or in the cloud.

The Components

We already discussed one of the components, which is the runner. Let’s explore the rest.

• Workflows A single workflow is a YAML file, defined in your repository's .github/workflows folder. It will run when triggered by an event in your repository (for example a Pull Request is opened), or they can be triggered manually, or at a defined schedule. a repository can have multiple workflows, each of which can perform a different set of tasks. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.
• Events As discussed, some events should happen to trigger workflow/s. This can be opening a pull request, issue, or push. Manually triggering the workflow is also considered an event.
• Jobs As you might already imagine, a workflow YAML file contains a set of steps that need to be executed. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built. So, a job is a set of steps in a workflow that is executed on the runner.
• Actions This is the building block of the workflow. It’s a custom application for the GitHub platform. Use an action to help reduce the amount of repetitive code that you write in your workflow files. Think about that as a script that takes arguments, does something and produces the output. For example, an action can pull your git repository from GitHub, set up the correct toolchain (install .NET, Go or Python on the machine/runner) for your build environment, or set up the authentication to your cloud provider. You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.
• Runners We already discussed this. Think about runners as servers that run your workflows when they’re triggered.

Example

Here is an example of a workflow YAML. But let’s go step by step

name: learn-github-actions
on: [push]

jobs:
 check-bats-version:
   runs-on: ubuntu-latest

   steps:

     — uses: actions/checkout@v4

     — uses: actions/setup-node@v4
       with:
         node-version: ‘20’
     — run: npm install -g bats
     — run: bats -v          

1. In your repository, create the .github/workflows/ directory to store your workflow files.
2. In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the above code (make sure the spacing is correct).
3. Commit these changes and push them to your GitHub repository.

Your new GitHub Actions workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository.

If we break down the above example line by line, we have:

• A workflow with the “learn-github-actions”, which will appear on the GitHub UI with this name

• on: [push] defines the trigger event. In this case, whenever someone pushes a new code to the repository or merges a pull request.
• jobs groups together all the jobs that run in the workflow. You can have more than one job of course, but this example has only 1 job defined.
• Next line defines the job name which will appear on the UI again.
• runs-on is to say GitHub which runner we want to use for this job.
• steps groups together all the steps that run in the job.
• uses keyword specifies that this step will run v4 of the actions/checkout action and actions/setup-node actions. And again, these actions are coming out of the box from the GitHub Actions marketplace. And there are thousands of ready actions that you can use.
• The run keyword tells the job to execute a command on the runner. For example npm to install some package and then use that package to run a new command.

And on GitHub UI you can view the above pictures by navigating here