Now, it's time to build on top of our working GitHub Action to introduce the important bits for our specific use case.
That means that what we need to do is we need to add a
step that runs the Maven tests.
So again, I'm going to use pseudo-code to say, "Run: mvn test."
As I'm looking at that, I'm realizing that we probably have a few things we need to do first.
For example, we need to be able to use Java.
So, "install java" needs to be created first.
The other thing is that we're running Chrome during these Maven tests, and there's some interesting bits around how to run Chrome on a remote server.
So, I'm just going to add a comment here - "Handle remote server chromedriver".
With these three actions, when we complete them we will be able to see our tests running in GitHub.
So, let's work through them.
First, to install Java.
Here, we can rely on, again, a publicly available action.
So I can use the
uses command to call an action, which is called
setup-java and this is also on version two.
The interesting thing about setting up Java is unlike the checkout command, it requires certain parameters to be set.
We set these parameters using a
with the parameters
distribution, to indicate which Java distribution - we'll be using the default
zulu - and
Because our maven file is set up with Java version 16, I will also use
java-version: 16 here.
# Event name name: on_push # When the event should run on: push: branch: - "**" # This will run on all branches and must be quoted to be handled by yaml # What jobs to execute jobs: build_and_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 # install java - uses: actions/setup-java@v2 with: distribution: 'zulu' java-version: 16 # Run: mvn test # Handle remote server chromedriver
With Java installed, it's time to look at how to run our tests.
This is the first time we're going to be running a more custom step.
And so with that, I'm going to set a
name for that step.
name for this step is
Run tests with maven and within here, we need to tell it what command to do.
When we're using these publicly available actions, all of this is wrapped up in a nice package for us, but for here, we need to set the command ourselves by calling the
And under this, it's basically like running anything you can on a command line so for Maven, the command would be
But as we talk about the fact that this is like running anything on the command line, one thing we have to think about is where this is being run from.
By default, when you're running things in GitHub Actions, it runs from the root of your repository, or from the
selenium-webdriver-java-course directory, but that's not actually where Maven is, right?
Maven is inside of
webdriver_java and you can find that here with
pom.xml, so we need to tell GitHub Actions that as well.
The way that we do that is we tell it about a
working-directory and this tells it basically where to run the command, and for us, we want to run it in the
With this, we've been able to install Java, which will let us run
mvn test, so I can remove these two comments.
name: on_push on: push: branch: - "**" # This will run on all branches and must be quoted to be handled by yaml jobs: build_and_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-java@v2 with: distribution: 'zulu' java-version: 16 - name: Run tests with maven working-directory: webdriver_java run: mvn test # Handle remote server chromedriver
The thing is we're trying to run ChromeDriver and right now, the way that ChromeDriver runs on our computer is that we've installed ChromeDriver into a specific repository that is under
resources, but is your computer an ubuntu-latest?
Mine isn't - mine's a Windows computer.
In order to make this pass, we need to make sure that we are using the correct ChromeDriver in the different scenarios, both locally and remotely.
To do that, we have a little bit of code that helps us.
We can find this code inside of the
BaseTests, we can see here that during our
setUp, we are trying to set the
chromedriver, but we allow for an extension based on an environment variable called
RUNNER_OS environment variable is set to anything, as long as it's
null, then we will be using the
-linux extension for the ChromeDriver.
If I return to my actions file, I want to add this environment variable.
I can do that here inside of the step, or I can do it more globally.
Since this is a pretty global concept, I'm going to add it here at the top.
RUNNER_OS and I'm just going to say
As long as it's not empty, it will work.
While I'm talking about environment variables, it's probably valuable to add one more.
If I go back to
BaseTests and I scroll down to the other bits of the
setUp, I can see things like
ChromeOptions and in specific, the ChromeOption of whether or not it should be run
Headless means that you won't be able to see the browser window open.
This is an option locally, but it's actually a requirement when running on a continuous integration server, because they don't come with the necessary hardware to deal with a visual browser and so they can actually fail your tests for not having it.
Again, this is set by an environment variable - this time, the word
So I want to come back to my actions, add one more variable here called
HEADLESS_CHROME and I'm going to again say
name: on_push on: push: branch: - "**" # This will run on all branches and must be quoted to be handled by yaml jobs: build_and_test: runs-on: ubuntu-latest env: RUNNER_OS: true HEADLESS_CHROME: true steps: - uses: actions/checkout@v2 - uses: actions/setup-java@v2 with: distribution: 'zulu' java-version: 16 - name: Run tests with maven working-directory: webdriver_java run: mvn test # Handle remote server chromedriver
I don't need this product window open anymore so I'm going to close that.
Now, my tests know that they need to run on Linux and that they need to run headless, but I need to make sure that it has the ChromeDriver it needs for that.
So, I'm going to return to the same actions I took during setup, and I'm going to download another ChromeDriver.
Here I am on the ChromeDriver Download page.
I've been using ChromeDriver 94, so I'm going to open that and I'm going to have the option to download the Linux zip file.
I'm going to download that directly into my
webdriver_java/resources directory, and "Save".
Now, I can ask that to show me in the folder and I can extract that so I can get to the actual ChromeDriver itself.
Inside of this
chromedriver_linux64 directory, I can see a
chromedriver I can use, but if I try and put this in my
resources directory, it will overwrite the one I use for my laptop.
So what I'm going to do is I'm going to rename this, just like it is in the code, to
Then, I'm going to copy and drag that over to the
With that, I can do a bit of cleanup.
I no longer need the zip folder or this now empty folder, and I get left with a
chromedriver and a
chromedriver-linux in this folder.
I can see that in IntelliJ as well if I open up the "Projects" tab, I can see
It's now time for us to add these files to Git.
To do that, I'm going to use IntelliJ to commit and add these.
As you can see, I already have a commit message ready and it has an interesting note about making sure that the file is executable in order to be run.
In order to do that, I'm going to need to use the command line, so I'm going to commit these, but I'm not going to immediately push.
Here on the command line, I can check what the status of that file is.
I can do that using a command called
ls is to list the files and
-l gives me a little bit of extra information about those files.
I specifically want to list the files that are inside of
In here, I can see the WebDriver, the one I'm using on my laptop, is executable.
The way I can see that is this
x at the end of this first line.
chromedriver-linux though, is not executable - there's no
x on this line.
It doesn't matter if this is executable on my own computer, but it does matter that Git knows that it's executable.
So, to do that, I need to make sure that Git sets this file as executable.
I use a command called
git update index and I tell it what I want to update - so I want to change the mode of that file to be "+x" and the file I want to change is
git update-index --chmod=+x webdriver_java/resources/chromedriver-linux
git status, I can see that everything's ready now to be committed.
git commit this change - this is just a small one, so I can add it directly on the command line with the commit message "make chromedriver-linux executable in github".
Once those commits have been pushed, they can take a minute to run, but here I am with that commit having run on my GitHub Actions tab - I can see that it's failed.
When I click through and click into the "build_and_test", I can see what parts of it failed - namely, I can see that the "Run tests with maven" bit failed.
So, let's see how it failed.
Scrolling all the way to the bottom, I can see that there were two test failures.
One of which is the test that we know has been failing locally, which is this "ForgotPassword" test, and there was another test failure, which is this "WindowTests" failure.
This proves to me that the ChromeDriver successfully was able to run our Maven test in the remote server, which is fantastic.
But yet, I still have some work to do as a test automation specialist with making sure I get this test consistent and passing, and we don't have those failures, like the "WindowTests".
This is when having some observability into the system could help me with my job.
Continue on with the course to learn more about what types of observability we can extract and how to get those into a more usable format.