GitHub Actions makes it really easy to automate all your software workflows with automating CICD pipelines, Building, Testing and Deploying your code directly from your GitHub repository even without any third party integrations like Jenkins.
We can automate code reviews, branch management and issues and we can trigger any workflow with the GitHub events.
Here you can see and understand the big picture of GitHub Actions workflow.
I hope you have a basic idea about what GitHub events are. If you are familiar with Git & GitHub you should have worked with GitHub events.
- Pushing a code into a repository branch
- Opening & closing a pull request
- Code reviewing
- Opening and closing Issues
- Assigning issues
- Re-opening issues like that, We can trigger any automated workflow when a GitHub event is performed.
So actually this is the beauty of GitHub Actions.
GitHub actions are triggered inside a GitHub server. We can create multiple workflows & multiple jobs in GitHub actions. As you see on the above figure, each and every Job we create and script, is running on a separate virtual machine inside the GitHub server.
We can automate actions as steps inside each and every job such as step1 step2 step3...
Virtual machines in GitHub server which are also known as Runners.
A runner is also known as any virtual machine with the GitHub Actions Runner Application is installed. Because GitHub Actions Runner is the core application part of GitHub actions which allows to run/trigger any workflow in this platform.
Mainly there are two types of runners as you see on this figure such as GitHub hosted runners and Self Hosted runners.
GitHub Hosted runners are some virtual machines that github team provides us to use directly.
For example, Linux. Windows, Mac OS virtual machines are there with pre-installed software like GIT, CURL, NPM, YARN, PIP, NODE.
These GitHub hosted machines are ,
- Easy to use
- We can not customize it as we want.
- Fully maintained by the GitHub team.
Self hosted runners are the machines that we can manage and maintain as we want.
You have full control over the hardware, software, operating system of the vm and also the tools which need to be configured to automate some commands.
Most of the cloud companies like AWS Azzure GCP have developed their CICD automation action setups and published in GitHub Actions Marketplace for their clients.
Mainly In GitHub actions we have to work with YAML files. If you are not familiar with YAML format and YAML files please feel free to read this article about YAML.
First of all we need to have a repository and that should be in public.
- Specially note that private repositories cannot be used with GitHub actions in the free version of GitHub.
When it comes to the triggering point,
We have to create a folder called “.github‘ in the root of the repository and we have to create a folder called “workflows”, inside the “.github” folder. We have to create our own YAML file inside the “workflows” folder.
Here is the standard triggering point of GitHub actions.
Here you can see a sample screenshot of triggering a workflow.
- Actions window is where we can monitor our workflows.
- Here you can see the workflow name, and jobs on the left side of this window.
- GitHub actions logs every step in the automation very clearly
- When a step is passed, it indicates a green check mark or when a step is failed it indicates a red check mark as well.
Also we can debug those errors as well in this log screen when a step is failed.
First of all create a github repository and initialize it and create a yml file in the triggering point of the repository. (.github > workflows > sample.yml)
👏👏 Here is the basic structure...
name: Any-Name #Name of the workflow on: [push] # On which events this workflow should be triggered. We can use this as an array as well # on: [push, pull_request, issue] # We can specify events like this as well # on: # pull_request: # types: [opened, closed, reopened] jobs: run-shell-command: # Name of the job 1 runs-on: ubuntu-latest # Selecting a GitHub Hosted Runner (Here selected an ubuntu machine) steps: # Automated Steps of the job - name: echo a string # Name of the Step 1 (Optional) run: echo "Hello" # command of the step 1 - name: multiline commands # Name of the Step 2 run: | # Multiline commands of the step 2 node -v npm -v - name: cloning repo files into the vm # Consuming pre published actions from the marketplace uses: email@example.com # Signature of the action you want to use here from the market place run-windows-command: # Name of the job 2 runs-on: windows-latest # Selecting a GitHub Hosted Runner (Here selected a windows machine) needs: ["run-shell-command"] # If we want to run the first job before triggering the this job, we can set 'needs' steps: - name: Echo the Directory run: pwd
Please note that, keeping indents is a must when it comes to github actions workflows.
you can set many types of events to trigger the workflow in "on:" section as follows.
Events which can trigger a worfkflow Link
We can specify individual steps to be triggered for specific events as well with if conditions. (It will be explained in a separate article)
Once the scripting is done, you can push this into the remote repository and see how the workflow is triggering in "actions" window of the github repository.
Consuming public actions from the marketplace, an in-detail article will be available soon.
Hope you all enjoyed and learned something from this. Let me know your comments and suggestions in the discussion section.
This article is for giving you a start to GitHub Actions and giving a brief introduction regarding what GitHub Actions is and what we can do with GitHub Actions.
I will be writing few articles with some hands-on demonstrations how we can use GitHub Actions in real world.