A Crash Course on GitHub Actions

What is GitHub Actions?

GitHub Action is basically a CI/CD tool that is widely used in the Modern Tech world. It enables us to automate all of our software workflows. It helps us to create workflows that is able to build, test and deploy in many different environments. It is integrated with the GitHub which makes it easier to work with the repository in the GitHub itself.

The most common use of GitHub are:

1. Testing

2. Building

3. Deploying

GitHub Action Components:

Workflows:

GitHub provides with many configured workflows templates that any one can use or you can customize your our workflow. A workflow is an automated process or script written in YAML language that define to perform specific task. The workflows are stored in .github/workflows directory of your repository. You can create workflow for you every repository in GitHub.

A workflow is triggered by the event or series of event. For examples, If someone Pushes the code to the repository then the series of step will be implemented. If someone create the pull request a set of steps will be executed.

A workflow is made up of jobs, which consist of many septs to perform. Each jobs runs independently and can run on different environment. You can also make a job to run after the others jobs are completed in the workflow.

File Example:

name: Hello World Workflow

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v2

Components of workflows:

1. name: A descriptive name for the workflow

2. on: specifies the events that trigger the workflow ( If someone push to the main branch then this workflow will be triggered)

3. jobs: Defines what the workflow does

4. runs-on: Specifies the environment for the job

5. steps: Sequential tasks for the job to perform

6. uses: specifies a pre-built action or a reusable workflow that your workflow uses.

Why to use the Workflows?

• It helps in automating repetitive task like testing and building.

• It also ensure consistent processes across the team.

• It improves the efficiency and reduce error in the application development process.

Jobs:

Jobs represents the tasks that a workflow executed. Rach workflow can consists of oner ore multiple jobs . They can run sequentially or parallel depending on what you configure. Jobs are defined within a workflow and grouped under the jobs section that you have previously seen.

If you wan certain jobs to execute first before executing the jobs you can use the need keyword which enables the other jobs to run and process first.

Structure of the Job:

A job contains name which is identifier of the job , runner environment which is the operating system to use while running the job and the last one is the steps where you configure various steps that need to be done to get certain outcomes.

Example of single job as follows:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v2

Example of multiple jobs with need:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v2
  test:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Print Hello World
        run: |
          echo "Hello, World!"

This is how you use the need keyword so the previous job called build will be executed first.

Steps:

jobs are made up of steps, which define the individual tasks or actions the job performs. Steps are executed sequentially within the job. If a step fails, the job typically stops unless explicitly configured to continue.

Types of Steps:

1. Action steps: Use pre-built GitHub Actions (specified using the uses keyword).

2. Command steps: Run custom shell commands or scripts (specified using the run keyword).

Structure of Steps:

• name: a optional human readable label for the steps

• uses: specifies a prebuilt action to use

• run: execute the shell commands

• with: it passes inputs to action (optional)

• env: defines environment variables for the steps (optional)

Actions:

Actions are the building blocks of GitHub Actions workflows. They are pre-defined tasks or commands that can be included in your workflow steps to automate specific operations. Think of them as reusable modules that save you time by abstracting complex logic into simple, ready-to-use components.

Why should we use Actions?

• It reduced the need to write script for every tasks.

• You can create your own action or use the public actions which is shared by GitHub community.

• It can be used across multiple workflows and repositories.

Types of Actions:

1. Pre-Built: It is available in the GitHub Marketplace, where you can find actions for testing, building, deployment, notifications, and more.

2. Custom: You can create your own actions using JavaScript and Docker Containers.

Example of a popular action that clones your repository:

 steps:
      - name: Check out repository
        uses: actions/checkout@v2

Where action/checkout@v3 is the action that clones your current repository where your workflow resides.

Runners:

A runner is a server that executes your workflows. Each runner listens for workflow jobs, runs the job when triggered, and reports the results back to GitHub.

Types of Runner:

1. GitHub Hosted: GitHub-hosted runners are virtual machines provided and managed by GitHub. They come pre-configured with popular tools, libraries, and programming environments.

    jobs:
      build:
        runs-on: ubuntu-latest
   

2. Self Hosted: Self-hosted runners are servers that you own and manage. You can use your infrastructure, whether on-premises or in the cloud, to execute workflows.

    jobs:
      greet:
        runs-on: self-hosted
   

   Setting Up a Self-Hosted Runner

   1. Go to your repository settings and navigate to Actions > Runners.

   2. Click Add Runner and choose the desired operating system.

   3. Follow the instructions to download and configure the runner.

   4. Start the runner, and it will connect to GitHub

Comparison between runners:

Setting Up the First GitHub Action

• Step-by-step guide to creating a simple GitHub Action:

  1. Create a repository (or use an existing one).

  2. Navigate to the "Actions" tab.

  3. Use a pre-built template or create a .yml file in the .github/workflows directory.

  4. Write a basic workflow and test it.

Best Practices:

• It is advised to keep workflows modular and reusable.

• Always Secure secrets and sensitive data.

• Regularly update dependencies and actions.

• Monitor and debug workflows effectively.

Conclusion:

Overall, GitHub Actions enhances collaboration, consistency, and automation, making it an essential tool for modern software development in CI/CD pipelines.

Reference:

GitHub Documentation

TechWorld With Nana

glich.stream