Beginner's Guide to Github Actions

Beginner's Guide to Github Actions

Automate your workflow

What are GitHub Actions?

GitHub Actions is a continuous integration and delivery (CI/CD) platform that helps you automate your software development workflows. With GitHub Actions, you can build, test, and deploy your code right from your Git repository.

You can also use Actions to automate other tasks, such as managing issues and pull requests, deploying applications, and triggering custom workflows.

GitHub Actions is a way to create custom software development lifecycle (SDLC) workflows directly in your GitHub repository. You can use Actions to automate tasks such as building, testing, and deploying your code, as well as more complex tasks like releasing a new version of your software. Now a question may arise in your mind Is Github Actions a CI/CD platform? No, CI/CD is just one of the many workflows that we automate using GitHub Actions.

How to use GitHub Actions?

To use GitHub Actions, you create a workflow file in your repository. This file defines the steps in your workflow and the events that trigger the workflow to run. You can use pre-built actions from the GitHub Actions Marketplace or create your own actions to customize your workflow.

GitHub Actions is a powerful tool that can help you streamline your software development process and improve your team's productivity.

What are workflows?

In GitHub Actions, a workflow is a defined series of tasks that can be automated and triggered by certain events. Workflows are defined in a YAML file that lives in your GitHub repository, and they can be triggered by various events, such as when code is pushed to the repository, when a pull request is opened or closed, or when a new issue is opened.

Each workflow consists of one or more jobs, which are individual tasks that are run as part of the workflow. Jobs can be run sequentially or in parallel, depending on how you define the workflow.

Using GitHub Actions, you can automate a wide range of tasks, such as building and testing code, deploying code to production, or publishing documentation. You can also use Actions to automate processes such as code review, issue triage, and release management. Consider contributing to a large open source organization that consists of many issues, maintainer, and contributor assigning issues to each contributor, checking each PR gets hectic here's Github Actions plays an important role by automating as many things as possible.

Creating workflows

To create a workflow in GitHub Actions, you'll need to create a YAML file in your repository's .github/workflows directory. You can name the file whatever you like, but it's a good idea to choose a descriptive name that reflects the purpose of the workflow.

In this example, the workflow is named "github-actions-demo" and it is triggered by the push event, which occurs whenever a new commit is pushed to the repository. The workflow consists of a single job called "build", which runs on the latest version of Ubuntu and has steps that runs the make build command.

In the main.yml file, which is present ./github/workflows/main.yaml you'll see a commented-out section called jobs. This is where you'll define the tasks that make up your workflow.

name: github-actions-demo.        #describes what your file does

on:                               #On is a [REQUIRED] field ,details                             
                                  #the EVENTS 

  push:                           #push & pull on branch main is a 
    branches: [ "main" ]          #Event that will trigger aworkflow
  pull_request:
    branches: [ "main" ]

jobs:                             #Jobs are mainly set of steps 
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Install dependencies
      run: npm install
    - name: Run tests
      run: npm test
  • name: The name of the workflow describes what the workflow is doing.

  • on: on is a list all events that will trigger this workflow. So in this case, if someone pushes to the main branch or every time a pull request gets created with the main branch as a target the workflows mentioned inside jobs get executed.

  • jobs: Jobs are mainly set of steps that contain different workflows that gets executed once any event inside on is triggered. There can be multiple jobs.

  • build: build here is <name> of the job, could be arbitrary.

  • Whenever we want to build an application or run a test we need to checkout the repository or the code first. So "actions/" path in GitHub is where predefined actions are hosted. This is present so that the user does not have to write it. The checkout@v2 after checkout is the version of checkout. so basically uses runs predefined actions that is created by someone else and is an action. you can check what checkout option does in our file here

  • and The "run" attribute helps us to run a command line command.

One important thing to note here is all the jobs would run in parallel we have here a single job named build but if you create another job to say deploy the code to some repository then that job would run in parallel by default but you can override this setting by using needs: build line in your next job that you create.

GitHub Actions enable you to use others actions in your workflow which just makes your workflow file small and speed up your workflow-building steps. Also, you can write your own actions and publish them to actions marketplace in GitHub which can be used by others.

That's all for now. Please like, share, and comment if you found this information informative. If you have any questions, please leave them in the comments section and I will do my best to answer them. Thanks for reading. Any feedbacks are welcome!! :) Connect me on Twitter | Github

References

GitHub Actions Tutorial - Basic Concepts and CI/CD Pipeline with Docker