Author – Shefali Kamble, Cloud Engineer
GitHub Actions is a CI/CD and general automation system introduced by GitHub. It is integrated right into GitHub and enabled by default in every GitHub repository. GitHub Actions help you automate tasks within your software development life cycle. It is event-driven, which means that we can run a series of commands after a specified event has occurred.
How GitHub Actions are Automated?
Every time someone creates a pull request for a repository, you can automatically run a command that executes a software testing script. An event then automatically triggers the workflow, which contains a job. The job then uses steps to control the order in which actions are run. These actions are the commands that automate your software testing.
The Components of GitHub Actions
Below is a list of the multiple GitHub Actions components that work together to run jobs. You can see how these components interact with each other.
The workflow is an automated procedure that you add to your repository. Workflows are made up of one or more jobs and can be scheduled or triggered by an event. Every GitHub repository can contain one or more workflows. Each workflow is defined in a separate YAML in the .github/workflows directory of the repository. The workflow can be used to build, test, package, release, or deploy a project on GitHub.
A workflow is triggered by one or more events. An event may be an internal GitHub event (such as a push, a release, or a pull request), a scheduled event (triggered at a specific time, like a cron job), or an arbitrary external event (triggered by a webhook call to the GitHub API).
A workflow consists of one or more jobs. A job contains a set of commands that will be run when the workflow is triggered. By default, when a workflow is triggered, all of its jobs run in parallel. However, you can define dependencies between selected jobs to make them run sequentially.
A job consists of a sequence of steps. A step is either a shell command or an action. All the steps of a job run sequentially on the runner associated with the job. By default, if a step fails, the subsequent steps of the job are skipped.
An action is a reusable unit of code which can be included as a step of a job. Actions can have inputs and outputs. You can create your own action or use actions shared by the GitHub community. Shared actions are distributed on the GitHub Marketplace, and there exist several thousands of them.
Each job runs on a specific runner. A runner is a virtual machine hosted by GitHub with an operating system of your choice (Linux, macOS, or Windows). You can also use a self-hosted runner, in which case you have full control of the runner’s hardware and software.
Creating a Workflow
Now that you know the basic concepts of GitHub Actions, let’s create a workflow. This workflow does nothing but print “Hello World!” to the standard output of the runner whenever a push to the repository occurs.
GitHub Actions uses YAML syntax to define the events, jobs, and steps. These YAML files are stored in your code repository, in a directory called .github/workflows. Below is the example of YAML syntax:
|– name: my-step|
|run: echo “Hello World!”|
Let’s go through the definition of this workflow:
- The name of the workflow is hello-world(defined by the name field).
- The workflow is triggered by the push event (defined by the on field).
- The workflow contains a single job with an ID of my-job(this is also the name of the job).
- The my-job job uses the ubuntu-latest GitHub-hosted runner (defined by the runs-on field). At the time of this writing, the ubuntu-latest runner corresponds to Ubuntu 18.04 LTS.
- The my-job job contains a single step named my-step. This step executes the shell command echo “Hello World!”.
Follow the below steps to create a workflow:
Step 1. In your repository, create the .github/workflows/ directory to store your workflow files.
Step 3. Push the changes to GitHub
On the left side, you should see your hello-world workflow. And since this workflow is triggered by pushes, and you just pushed to GitHub, the workflow has already been triggered and run. You can see this workflow run on the right side of the screen:
From now on, whenever someone pushes to your GitHub repository, this workflow will be triggered and a new run will be added on the right side of the above screen.
Step 4: To inspect the existing run of your workflow, click on it. This should take you to a new screen where you can see all the jobs of the workflow on the left side. Click on the my-job job and you should see all the steps of the job:
You can see three steps there, Set up job, my-step, and Complete job. The first and the last step have been automatically added by GitHub Actions. The my-step step is the step you defined in your workflow file.
You can click on every step to reveal more information about it. Go on and click on the my-step step:
And there it is — your “Hello World!” message!
Congratulations, you just created and run a GitHub Actions workflow!
Hope this article was helpful to make you understand about GitHub Actions. You can post your thoughts/queries in the comment section.