Basics of GitHub Actions for developers under 10 minutes

In this post, I am going to introduce GitHub Actions. If you are new to GitHub action this is a good place to start. I assume that you have a basic understanding of GitHub and some working knowledge of it.

What are GitHub actions?

• GitHub action is a platform for developers to set up CI/CD (  continuous integration & continuous delivery ), which means developers can automate building, testing, and deploying as they push their code to GitHub.
• GitHub Actions can also be used as a workflow automation tool based on the events that happen in your repository.

What are the components of GitHub Actions?

Before you use GitHub Action., you need to understand the core concepts behind it. GitHub Action is made up of workflows. A Workflow can have one or more jobs running sequentially or parallelly. A job contains individual tasks that are called steps.  A step can run commands( shell scripts ) or run an action (a reusable extension that we are going to talk about later ).

Each step in a job executes on the same virtual machine runner or container that you can define. Because of this, the action that makes up a step can share data between them.

Workflows

As mentioned before workflow can run one or more jobs. These workflows are defined in a YAML file in your repository. This YAML file is created at the root of your repository in the .github/workflows directory. So, how does a workflow runs? 

You can use GitHub events, set schedules, or external events ( webhook events ) to trigger running a workflow. In the case of GitHub events, for example, you can configure a workflow to run on a push/pull request event that occurs in your repository. 

Another important thing to know is that one repository can have multiple workflows carrying out different tasks.

Events

An event is a specific activity in the repository. As mentioned above, events can be used to trigger a workflow. An event can be a GitHub event,  a schedule, or an external event( webhook event ). You can specify the event in the YAML file( the workflow file). A complete list of events that trigger workflows can be referenced here. 

Jobs

 A job is a set of steps that executes in the same runner. A step can be a shell script or an action. Steps are executed sequentially and depend on each other by sharing data from one to another. In addition, steps can access the file system of the virtual environment (the OS that they run on ).

Jobs, by default, have no inter-dependencies and thus can run parallel. However, you can configure individual jobs to be dependent on each other. When you configure it like that, one job needs to wait for another job to complete before it can run.

Actions

An Action, the smallest portable building block of a workflow, is a reusable extension that you can reference on a step in the workflow file.  Actions help reduce the repetitive code in the workflow file. You can find different types of action capable of doing a variety of tasks the in the GitHub Marketplace. You can make a reference to these actions in the workflow file. In addition, you can also write custom actions. 

Runners

The runner is the server that runs workflows. A single runner can run a single job at a given time. GitHub provides different types of runners for Ubuntu Linux, Microsoft Windows, and macOS ( standard GitHub-hosted runners ). It also provides another type of runner called larger runners for teams and Enterprise cloud plans. These runners come with more RAM and CPU capabilities. 

Additionally, you can also configure self-hosted runners. These are provided so that you can have more control over hardware, operating system, and software tools that you can use. 

Creating a workflow file

Now lets us see how to create a workflow file. 

1. First, create a repository in your GitHub
2. At the root of the repo, create .github/workflows/ directory, and then
3. Create a myfrist-github-action.yml file in  the.github/workflows/ 

Note: you can do steps 2 and 3 at the same time

How to create .github/workflows/myfrist-github-action.yml

1. Click on the code button on GitHub
2. Click on the Add file drop-down menu and click on create a new file
3. Now enter .github/workflows/myfrist-github-action.yml

name: first-github-action 
run-name: This is a test run_name 
on: [create] 
jobs:
  print-message:
    runs-on: ubuntu-latest
    steps:       
      - name: Run a one-line script
        run: echo ${{ github.actor }}, did you create a branch named ${{ github.ref_name }} on your repo?

We will see the meaning of the above lines now

name: first-github-action

This is the name of the workflow displayed on the “Actions” tab of the GitHub repository.

run-name: This is a test run_name

The name for workflow runs generated from the workflow. This appears in the list of workflow runs on the “Actions” tab of your repository.

on: [create] => The event that triggers the workflow

jobs: => Marks the start of jobs running 

print-message: => The name of the job. Do not use # or any other special characters as It might lead to unexpected errors.

steps: Indicate list actions or commands of the job ( “print-message” job )

name: => name of the script

run:

run keyword tells the job to execute the command specified on the runner. In this case, the command is the echo command that prints on the terminal of ubuntu( runner )

${{ github.actor }} is an expression. This expression uses github.actor. The github part of github.actor is called Contexts. Contexts are objects that can access information about workflow runs, runner environments, jobs, and steps. 

actor of the GitHub context is a property that displays the username of the user that triggered the initial workflow run.  

${{ github.ref_name }}  is also another expression that uses GitHub Context and property to access the name of the branch( in this case the newly created branch ).

githhub.actor and github.ref_name are used in this example to actress default environment variables on GitHub. Therefore, you can replace the above echo command below

run: echo $GITHUB_ACTOR, did you create a branch named $GITHUB_REF_NAME on your repo?

You can learn more about workflow syntax and workflow commands on GitHub actions docs.

GitHub maintains a large collection of actions you can use in your workflow file. As mentioned before using these action reduce your custom code. One such action that most Workfiles use is action/checkout. Here the action is the owner of the repository and checkout is the repository. You can reference a specific version of the checkout using @ sign. So, if you want to use an action outside of your repository like the checkout action, you would use action/checkout@v3.  The checkout action makes a clone of your repository on the runner.

You can modify the above YAML files as below.

name: first-github-action
run-name: This is a test run-name
on: [create]
jobs:
  print-message:
    run-on: ubuntu-latest
    steps: 
      - uses: actions/checkout@v3
      - name: Run a one-line script
        run: echo ${{ github.actor }}, did you create a branch named ${{ github.ref_name }} on your repo?  

The uses attribute here tells what actions to be used. Actions are reusable blocks of code that perform a specific task or operation. As mentioned before you can create your own action ( custom actions ) or make a reference to an action on the GitHub Marketplace.

Conclusion

GitHub actions provide a platform to automate build, test and deploy your code as you develop your software product. You can also use it to automate workflow. The main component of GitHub actions are workflows, events, jobs, actions, and runners.