Getting Started with GitHub Actions

Every software industry nowadays is adapting continuous integration and continuous delivery (CI/CD) platforms to reduce time and effort in the software release process. One such CI/CD platform is Github's Github Actions. Before starting, if you don't know what CI/CD is, then let me tell you, CI (Continuous Integration) basically means automating a build and test phase of a software release cycle. And CD (Continuous Delivery) means to deliver or release it to the customer continuously. So, together they complete a whole release cycle.

Now, let's get back to Github Action which itselft is a CI/CD solution. Github Actions allows a developer to automate worflows like issues, pull requests, commits, merging almost eveything within github. Now it can be creating a pull request, merging it, assigning someone into the pull request. In fact you can also set organization rules, for example, assign developer permissions etc using this feature.

Now let's take a dive into the details of Github Action. Every Github Action is a workflow that consists of some core components like events, jobs, steps, actions, and runners. Let's explore them in detail.

Workflow:
A workflow is a configurable automated process consisting of one or multiple jobs running parallelly triggered by events. They are typically declared in YAML files and reside inside .github/workflows directory of a GitHub repository.
Events:
Events are basically the defined triggers that start a workflow. For example: Creating a pull request, Pushing a commit into the repository, A defined scheduled cron time, Merging Pull requests etc can be an example of events.
Jobs:
Jobs are the executed tasks in a workflow that runs after an event is triggered. A workflow can have one or multiple jobs running in parallel.
Actions:
These are the most interesting things in a GitHub workflow. Actions are basically some particular tasks bound as a single package that you can use in any action workflow or you can also make your own.
Runner:
A runner is a series of tasks in a workflow that are executed in a single job. Every runner is responsible for executing a single job.

Setting Up A Basic Action Workflow:
Now let's set up a basic action workflow to see how it works. To do that, let's create a demo repository on GitHub.

1. Inside that repository create a directory named .github and inside that .gihub directory create another directory workflow. So, basically, it will be .github/workflows
2. Inside that .github/workflows directory create a yaml file named demo-workflow.yml
3. Copy the following yaml config into that file. (Courtesy of Github Docs)

name: GitHub Actions Demo
on: [push]
jobs:
 Explore-GitHub-Actions:
 runs-on: ubuntu-latest
 steps:
 - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
 - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
 - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
 - name: Check out repository code
 uses: actions/checkout@v3
 - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
 - run: echo "🖥️ The workflow is now ready to test your code on the runner."
 - name: List files in the repository
 run: |
 ls ${{ github.workspace }}
 - run: echo "🍏 This job's status is ${{ job.status }}."

1. Save it and then just push a random commit into that repository and see the workflow in action. Here, We have used [push] as a trigger, so it will trigger for every commit that has been pushed into that repository.

Now let's elaborate on the above workflow in detail.

1. Here on the first line "name:" is basically the workflow name. You can set this to anything that resembles that workflow. If you omit "name:", GitHub will set it to the workflow file path relative to the root of the repository.
2. In the next line "on:" is basically used for the trigger purpose. This is our event trigger. Here, we can use more event triggers like fork, created, and deleted and also particular events like pull_requests, issues etc. for example:

on:
  pull_request:
    types: [opened, reopened]

This will trigger an event whenever a pull request is created or reopened. Also, you can create multiple custom labels and use them as a trigger using the label's name. For more action triggers take a look at this article: Events That Trigger Workflows

1. The third line is the jobs part. Here we will define our tasks that will run after the event gets triggered. Inside jobs, there's a section titled "runs-on:" This is basically the environment where the tasks will be executed. In the above case, this is "ubuntu-latest".
2. In the steps section, we have defined an "uses:" section. This is basically the action's part. Here, you can use any pre-defined action workflow or make your own action workflow and then can use it by just mentioning the action name like this one actions/checkout@v3. Here, we are using checkout action workflow which basically clones our repo to a runner, so that we can further run tests on it, deploy it or perform any other tasks on the code. So, guys that's all for now. To learn more about github actions take a look into github's official documentation about Github Actions here: https://docs.github.com/en/actions/learn-github-actions Happy Automating!