Introduction to GitHub Actions

Introduction to GitHub Actions

You may have come across GitHub repositories that have a response for every event you carry out like, making a pull, creating an issue, or commenting on an issue, and several other effects that occur in a repository when you make a contribution. All these are as a result of Github actions.

GitHub actions

These are a set of instructions that help you automate any GitHub process and effect on GitHub. It makes it easy to automate all your software workflows, and is responsible for caring out the task of building, testing, and deploying codes from GitHub. GitHub Actions also provides the facility to build end-to-end Continuous Integration (CI) and Continuous Delivery(CD) Using GitHub action saves the stress of transferring all your files to a production server after each contribution made to the repository.

Screenshot 2020-11-24 at 17.21.13.png Executing automation occurs every time someone executes any events ranging from, pull request, push, pull, issue, comment, clone, and many more including your own unique code review tool in a repository. So, whether you intend on building a container, deploy a web service or automate welcome message for contributors there are actions automated for that, in the GitHub marketplace.

Screenshot 2020-11-24 at 17.06.30.png

The core concepts of Github actions

Actions:

Actions are the smallest portable building block of a workflow and can be combined as steps to create a job. You can create your own Actions or use publicly shared Actions from the Marketplace.

Event

Events are specific activities that trigger a workflow run. For instance, a workflow is triggered when somebody makes a push to the repository or when a pull request is created. The push can be classified as an event.

Job

This term refers to all the tasks in a single workflow. It is required for all of jobs to complete their execution to prevent the failure.

Workflows

A workflow is the config file and is made up of one or more jobs and can be triggered by an event. Workflows can handle common build tasks, like continuous delivery and continuous integration that is, the workflow can be used to build, test, package, release, or deploy a project on GitHub.

Steps

Steps are a set of tasks that can be executed by a job. A step is an individual task that can run commands or actions in a job.

CI/CD Pipeline

The CI and CD pipeline is a process which is similar to a software development lifecycle. These tools are popular for a good reason. They help us automate the application lifecycle, fully or partially.

CI-CD-Pipeline-CI-CD-Pipeline-Edureka-2.png

Image source

  • CI: If you have an automated process that starts with a push to a code repository but ends in a way that manual actions are needed afterwards, you are doing continuous integration.
  • CD: Imagine you have an automated process that starts with a push to a code repository and ends with a release deployed to production without any human intervention, this is how continuous deployment works.

Understanding the workflow file

The workflow is defined in YAML files are stored in your code repository, in a directory called .github/workflows. Within a workflow you will see:

Name: The name of your workflow that is displayed on the Github Actions tab of the repository. If you omit this field, it is set to the file name. name: Continuous Deployment

On: The On keyword defines the Github events that trigger the workflow. You can provide a single event, array or events or a configuration map that schedules a workflow.

on: push
or
on: [pull_request, issues]

Jobs: A workflow run is made up of one or more jobs. Jobs define the functionality that will be run in the workflow and run in parallel by default.

jobs:
  my-job:
    name: My Job
    runs-on: ubuntu-latest
    steps:
    - name: Print a greeting
      run: |
        echo Hello there!

Env: Env defines a map of environment variables that are available to all jobs and steps in the workflow. You can also set environment variables that are only available to a job or step. env:

  CI: true

Runs-on: The runs-on keyword lets you define the OS (Operating System) your workflow should run on, for example, the latest version of ubuntu. runs-on: ubuntu-latest

Build matrix: A build matrix allows you to test across multiple operating systems, platforms and language versions at the same time. You can specify a build matrix using the strategy keyword and pass it to runs-on.

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]

Why GitHub Actions

Build into Github: Github Actions is fully integrated into Github and therefore doesn't require an external site, everything is in place making it convenient.

Great free plan: Actions are completely free for every open-source repository and can be accessed by anyone.

Multiple CI templates: Github provides several templates of CI that are easy to get started with and you can easily include these in your code.

Conclusion

GitHub actions can do a whole lot more than just CI! You've got basically the whole API at your fingertips as inputs and outputs. You can write individual tasks, called actions, and combine them to create a custom workflow according to your preference. Next on this series, I will give a detailed guide on how to set up an action in This Article