Hi folks, In this short blog, we will explore more about Selenium, the testing tool we love and that is most often used, using Github action. You could wonder, however, why we combine the GitHub action with the Selenium framework and what the circumstances are. So let’s skip the introduction of Selenium as everyone is already familiar with the fundamentals of it. Instead, let’s begin our adventure by giving a quick overview of Github action.
what is GitHub Action?
GitHub Actions are the most well-known, significant, and optimistic CI workflow mechanism. When combined with CI/CD for testing and delivering products without the help of outside tools, GitHub Actions not only take a little time to set up but are simple to use. Users may also manage branches, evaluate codes, merge services, set up services, and automate successful builds.
Any GitHub repository project that we visit will have a number of menu tabs, as seen in the example picture below.
The area of focus in the above diagram is the red-highlighted box, which contains several GitHub processes and GitHub Actions components.
Demonstrating how we create GitHub Action workflows
Users will see a view attached to the screen below when they open the GitHub Actions page for the first time and before making any customizations.
We could also observe that GitHub automatically suggests users set up a potential process to be preferred at the top of the page.
Let’s say a user chooses one of the following choices based on the demands of the project. The user is then automatically given auto-generated scripts in the form of a YAML file, which can then be customized as needed and committed to the current GitHub repository.
For Example:-
As you can see in the screenshot above, I’ve highlighted the box containing Java with Maven in red, as per our current project demands, because I use Java as my programming language and Maven as a build automation tool that is usually used for Java projects, and my present project is centered on running Selenium tests in many browsers.
Most important thing:-
As soon as the relevant commands and instructions are added to the YAML file, committed, and uploaded to the GitHub repository, we will start to see that the workflow is automatically activated. The same GitHub Actions tab is where the remote build begins to execute. We can also view the build run’s status on the same page.
To have a better understanding of action workflow, we must first become familiar with the workflow file structure so let’s start with the basics first.
Workflow File Structure
Multiple processes that each construct a separate set of tasks needed for building, testing, and deploying may be specified for a single GitHub repository. The CircleCI configuration (YAML) file format and the Jenkins file format are quite similar to the workflow file structure. Therefore, when working with YAML files, we must remember that we cannot input improper formats and that we must adhere to the right indentation, colons, and dashes throughout the file, which is mostly in the form of key-value pairs, lists, and maps.
As mentioned earlier, GitHub Action offers automatically generated scripts based on the demands of our project. When we examine the syntax of the instructions used in the previous YAML file, we can observe the following:
- Name of workflow
- On Attribute
- Jobs
- Job name
- Job runner’s information
- Job Steps
Let us explore all these one by one.
1. What should you call your Workflow?
Typically, individuals offer the name of a process associated with our project’s operation or a set of features. However, if we want to have many processes to design a CI pipeline to execute tests with Selenium GitHub Actions, we need to label them appropriately. It should also be noted that this is not a required field, and if left blank, GitHub will generate a default name for us based on the file’s location and name.
2. When to trigger the Workflow?
This is the second stage in developing an effective process. We must define when the task flow starts after naming it.
The ‘On’ attribute is required and is regarded as a vital step to include in every workflow since it allows the user to specify when to start the process in GitHub Actions.
Basically, in this phase of the workflow, we indicated which branches to activate and what operation to use. let’s explore more about the operation below.
There are several methods for starting the process, including:
- push
- pull_request
- release
The operations list above represents the most common operations performed by every user in the action workflow file. Still, we also have some more operations that we use in some exceptional cases.
3. Where do the Build Jobs run?
Based on the user-chosen build machine configuration, primarily from the below list of predefined GitHub supported VMs with different types of versions.
- ubuntu-latest
- window-latest
- macOS-latest
below images show the proper syntax to define the virtual machine in which jobs run
How do you set up the build runs’ steps?
Essentially, this is a phase of the workflow in which we declare the name of the task, and steps, and install the necessary things for the job running.
We should be aware of the following points to have a better understanding of the jobs executed in the action workflow:
- At least one job must be present in every process.
- By default, all workflow tasks are executed in parallel.
- Each job may have several job steps.
- If any task must be done in a specific sequence, such as in a CI pipeline, where the test job must run after the build process, we may include a “requires” dependence in the test job.
How to manage your workflow runs?
When a push or pull request is made with code from the repository, the workflow becomes active, and the most recent build runs of GitHub commits in PR are automatically linked.
Before managing the workflow runs, let’s explore more about it.
As per the above image, we can get the complete build run and the details view of anyone built with a single click of the selected workflow.
In the above image, we have test_1, the job name, and as you can see, all of the stages beneath the jobs are passed, indicating that the workflow build is successful. If any of the stages in the given jobs fail, the workflow fails as well.
That’s all about viewing the report and details of the recently built run. Let’s explore more about the number of operations by which we can manage our action workflow runs.
- Deleting a workflow
- Disable a workflow
- Canceling a running workflow
- Re-running a workflow
- Creating Status badges
Conclusion
In this blog, we learned the fundamentals of using GitHub action with Selenium, and I also attempted to explain why we integrate and how it functions with the Selenium framework using clear, concise examples. Additionally, we had a basic introduction to setting up the link between the Github action and the Selenium framework. In our upcoming posts, we will go into greater detail on this.
Till then, Happy learning, happy sharing!
You may also click on these simple links to learn more about this integration here
