GitHub Actions -

GitHub actions is a CICD ( Continous Integration / Continous Deployment ) platform for automating build, test and deploy processes, with GitHub actions pull and push requests can be easily validated and verified.

Let us understand GitHub actions with an example!

Jack and Maria are working on a web development project, jack pushed the source code to the GitHub repository, and Maria wants to make changes to the code, so she pulled the source code from the repository, made some changes to it and again pushed the updated source code to the repository, at this point on push event gets triggered and verifies the code, but the build fails as there was an error in the code, as a result, maria code was not merged with the codebase.

Components of GitHub Actions

• Workflow - A workflow is an automated process that may be programmed to carry out one or more tasks. A YAML (Yet Another Markup Language) file that is checked into your repository contains the workflows. They can be manually started, by a repository event, or according to a predetermined schedule.

• Events - Events are the conditions or actions at which workflows will start. There are various events that will ultimately cause the GitHub actions to check for workflows, such as when someone pushes newly committed code to the repository, opens an issue, or submits a pull request.

• Job - A job resembles a group of workflow phases that are executed by a single runner. A shell script or an actual action might be used to describe each stage.

• Action - An action is a GitHub Actions platform-specific custom program that performs a sophisticated but regularly performed job.

• Runners - In simple terms, runners are the servers that execute the workflows built by you. Just like a C++ code needs to be compiled first using mingw and then run, similarly when the workflows are triggered, a runner executes them.