LambdaTest TeamGitHub Actions offers Continuous Integration workflows (CI). There are many triggers from which they can be invoked. Contributors increase their confidence in their code by performing automation against each commit.
In this insightful session of the Testμ Conference, Gandhali Samant, Director, Cloud Solution Architect, Digital and App Innovation, Microsoft, joined Mudit Singh, Director Marketing, LambdaTest, to learn all about GitHub actions for test automation and how GitHub actions can help testers & developers execute tests on LambdaTest platform.
At GitHub, Gandhali Samant is now in charge of the Enterprise advocacy charter for the APAC region. Gandhali has worked with numerous MNCs in India and internationally for over 20 years in the IT industry. She worked at Microsoft for eight years before joining GitHub, where her last position was as an engineering leader focused on strategic clients in Europe and Asia. Gandhali, who graduated from the University of Mumbai with a degree in computer engineering, also has a master’s degree in computer science from the Florida Institute of Technology.
“Automation is a powerful tool” — Gandhali Samant.
Automation can be tough and can sometimes prove to be costly if not done right. In any automation, there is always overhead when you start, spend time in automating, spend more effort, costs for automating. People need something where the automation time can be reduced, and you can get an automation tool to start automating your workflows quickly, and that’s where the feature of GitHub can have actions. They can help you automatically build and test your projects which is today’s topic by Gandhali.
She walks the attendees through the architecture of how to write the actions, where they are helpful, and then dives into GitHub actions specifically for test automation. She will also explain different test automation scenarios from UI Testing using the different frameworks and browser testing.
This is the standard Software Development Life Cycle. Plan, Code, Build, Test, Release, Deploy, Operate, Monitor. But many things within this software development life cycle could be automated using GitHub actions and which can make your life easy. So starting with the planning phase, we have a lot of issues, and project boards and many things could be automated.
She further explains with an example. One of her customers had a product feedback site where external customers could give product feedback. But they had built automation where that product feedback, as soon as it is created directly, gets into a repo and becomes part of their backlog. So they don’t have to manage and sync two different systems. You can automate the workings of your project board as you start coding. In all of these phases, we can automate a lot of stuff.
GitHub actions let you automate, customize, and execute the software development workflows.
They are stored as code.
Live logs and visualized workflow execution.
Matrix builds.
Built-in secret store.
Option to use GitHub hosted runner or your own.
How do actions work? — Architecture
Next comes what we refer to as the workflow. It begins with an event, just as with any other automation. A trigger, such as an event, might instruct your process to awaken and begin running. It might include the creation of an issue or a pull request, a scheduled event, or a manual event. However, the event is the most crucial factor because it will start your action workflow. Workflow is made up of numerous jobs. By default, each of these tasks runs concurrently. You are free to run them in order if you choose.
Each of these tasks again consists of many steps. Each of these phases inside a job is always executed in order. You also have what we refer to as the “Action” component within those steps. The idea of an action component makes a task come to mind. For instance, whether you want to check out your code, create an application, or deploy a website, these are all separate processes that may be completed using different actions. Actions can also be substituted using shell commands. To test anything, for instance, you could wish to run a command.
The runner is a VM constantly listening for the next available job. When it finds a job available, it will pick it up and start running. One important thing about runners is it takes one job in its entirety. You cannot break up jobs between multiple runners. The benefit is that you can use the file system of runner, you can store data, and pass data between two different steps because it’s all in one environment. So the runner runs these actions, and it also logs the result. It creates a step-by-step visualize log and sends it back to your GitHub repo.
Structure:
It starts with a simple YAML file. You can name it anything but the location is important. This location has to be the root of your GitHub repo. That’s where all the actions or workflows reside, and this is a standard YAML file structure. She explains one by one each part of it.
There are three different kinds of events:
- Webhook Events
Pull Requests
Issues
Push
Scheduled Events
Manual Events
There are two types of Runners:
- GitHub Hosted Runner
2 core GPU
7GB of RAM
14GB SSD disk space
OS: Windows, Linux, macOS
S/W installed: wget, AWS CLI, Java, etc.
- Self Hosted Runner
Custom Hardware configurations
Choice of OS not offered by GH-hosted runners
Create your custom labels
Reusable unit of codes that can be referred to in a workflow. GitHub runs actions in Node.js runtime or Docker containers. There are three types of Actions. They are:
A Public repository.
The same repository as your workflow (local actions).
Published docker container image.
Third-Party/Marketplace Actions:
The above slide represents the GitHub marketplace. Many actions are already created. It gives detailed information about the version and parameters if clicked. It also provides code samples and a link to the GitHub repo to be used within the workflow. Every Action has action.YAML in it where it is using docker.
She further demonstrates an example using Visual Studio Code. To get an idea of what she demonstrates, peep into the full video.
Also, she asks to visit the lab.github.com, and there are lots of things you can do with DevOps and GitHub and actions. You can run your hardware for free with self-hosted runners. All the GitHub actions are entirely free for public repositories. If you have any open source code or are using any projects on public repositories, you can use it for free.
It was indeed an insightful session with Gandhali. The session ended with a few questions asked by the attendees to Gandhali. Here is the Q&A:
Can we trigger a pipeline of a repo from another repo? For running test automation written in separate repo triggering from development repo pipeline.
Gandhali: No, GitHub actions are local to the repo. I mean, they have control of the core of the repo, and there is something called nested repositories, and that’s where you can try this. I can try and come back to you, but in a normal way, GitHub actions generally run within the scope of its repository. So they can do anything with the code in the same repository where the action resides.
Can you quote some best practices when working with GitHub actions as per your experience?
Gandhali: The best practice is to write your workflow. First of all, actions could confuse the way we use the word. So GitHub action is a feature. But I showed you the workflows that use the pre-created actions, which are a marketplace or could be on public repositories. Anytime you build a workflow, first, see if the steps or actions you need within your workflow are already available, are publicly available, and you know that will reduce a lot of your efforts and time.
Secondly, there might be some scenarios where you have to create your actions or you have to create your tasks. At that time, you need to think about whether they could be publicly made available, so if you create it in a docker container and publish that container, that would be a good way to validate your code and make it open source and get feedback about it. You have to take care of your secrets so make sure your secrets are always stored in a secret store.
If you are writing actions specifically for your enterprise usage, you might want not to make them public and keep them local. At that time, you can make the scope of the secrets also at an organization level, so there are a lot of different things that you can look at you know, depending on your use case or where you are using these actions whether to use open source code or using it for enterprise or company.
Is it possible to deploy a staging or test environment within GitHub and run a post-deploy e2e test?
Gandhali: You are the one who will execute in the staging test environment. You know your actions, but there won’t be a deployment environment. Since GitHub does not host the environment, the end-to-end test will require an environment from Azure or AWS. The functional tests that are included in code coverage testing and that can be performed on GitHub are what GitHub runners can do. This is where a solution like LambdaTest may help. Before deploying your site to a cloud, you can deploy it to localhost and perform end-to-end testing there. So give that a try, and it might also be an option.
How do you manage the latency between GitHub runner or device forms?
Gandhali: GitHub runner is just a VM that will run the action task. It is not going to run your application. It will run tasks like checking the code, building your code, and then deploying code to a certain. A certain environment like Selenium Grid or device farm is the environment where you can do that testing. So there would not be any latency because you are not in it. You are not doing the same thing between them. Your runner has a specific task of checking out testing and building your code and deploying it somewhere, whereas Selenium Grid or device farm has a different task of doing the end-to-end testing on different browsers. So there are two separate concerns here.
