We now created a new get hub repository.
We're now going to add in a little bit of code to our GitHub repo itself to make sure that we run our
tests anytime we create a new poll request to merge code into our master branch.
Let's take a look at a quick diagram.
Understand how this is going to work.
So we're going to use a feature on GitHub called GitHub actions on GitHub.
Anytime that you push some code Brady pull requests, all request closed.
Any time a repositories fought in a variety of many other events occur, that's going to trigger a event
internally inside of GitHub.
And when I say event right here, I'm not talking about an event inside of our Kootenays cluster.
I'm talking about an event on GitHub itself.
Whenever one of these events occurs, we can optionally run it, get hub action, a GitHub action as
a little script.
We can put any code inside that script that we want to somehow run commands, run our tests, deploy
our app.
We can do just about anything you can imagine.
So we're going to create a GitHub action that is going to trigger anytime that we create a pull request
to merge into the master branch.
We're also going to make sure that this GitHub action is going to run anytime that we update that Pullo
request as well inside of our GitHub action.
We're going to write out some code to take a look at each of our individual services and run the tests
inside them.
If any of those tests fail for any reason, we're then going to be told on the pull request that we
have created that something is wrong with our code and that we need to fix it.
Now, if you want to read more about GitHub actions on your own, you can take a look at the official
help page on GitHub and help get hub dot com slash, even if you're going for English slash actions.
And you can read a lot of documentation about it, have actions and how they work.
One of the most popular pages you're going to want to read, or most important, I should say, is events
that trigger workflows and this will tell you about all the different things that can occur inside of
GitHub.
That is going to trigger a get hub action or essentially run one these scripts are going to put together.
OK.
So let's put our first script together right now.
Back over on a repository on the very top ago.
Going to go to the tab that says actions.
We then get prompted with a couple of different options here, we can either make use of one that's
already been put together for us.
We're going to write our own from scratch, trying to find simple workflow and just it set up this workflow.
If you do not see something that says simple workflow or something like that, no problem.
You can click on any of the existing workflows on there, just on any of them.
Just hit setup.
You'll be taken to a page like this.
And once here, we're going to highlight everything and delete it.
So, again, it doesn't really matter which of those starting points to use.
Just click on any of them and delete everything inside this file.
The first we're going to do here is rename the file that we are creating.
We're going to rename this too.
S dot.
Yamal because it's going to run the tests inside of our project.
Now, inside this Ed, right here, we are going to write out some amount of code that's going to configure
this GitHub action in particular.
We're going to write out some configuration that says when we want to run this action, then we're going
to also write out the script that is actually going to run our tests.
So in general, there's going to be a little bit of just copy paste writing out what I write.
It's a special little syntax.
It is YAML technically.
But the actual options we write in here is just something you're going to learn over time.
The first day I'm going to do is provide a name for this workflow or this GitHub action.
I'm going to call it tests just to mirror the name of the file.
They're going to put in here.
And this autocomplete is really running me through a loop.
There we go.
We're gonna put in on this on section is going to determine when we are going to run this workflow.
So this would be where we configure, say, let's run this.
You get hub action whenever code is pushed or pull request created or so on, or you and I, we want
to run this workflow.
Anytime a pull request is created, they're going to put in pull request like so.
And that's it.
Now, technically, by putting in a play request right here, we're going to trigger this workflow more
often.
And if we just create a play request, we put in a play request by itself.
We can go back over this documentation page or events that trigger workflows.
I going to search on here for PLR requests.
And there we go.
So we right out.
Just pull request by itself, then technically this workflow is going to run anytime that a player request
is created or updated or re-opened by just running a play request.
That is going to determine when we run the script.
After that section, they're going to put in a jobs.
Then built.
And this autocomplete, again, is really here stating.
Inside this built section, we're going to write out runs on the wound to latest.
Are they going to put in a step section?
Inside of here, we're going to write out uses.
And then actions slash checkout's at the two.
So this job section right here is going to define some number of things that we want to do.
Whenever a pull request is created, reopened or updated in particular, we want to start up some kind
of virtual machine or really it is a container.
We are going to be running on the Ubuntu operating system, and the first thing we want to do inside
of our little script is take all the code out of our project.
That's what this uses.
Step right here.
Does.
We're then going to set up a series of commands to run inside of our project.
So I got to put in another Ouray entry here and say run.
And then I'm going to put in a command that is going to run all the tests inside of just my off service.
We'll start out with just the odd service for right now.
Inside, if you're going to put in c.D into the off directory.
And install all the dependencies inside there and run all of our tests.
And remember to run our tests.
We put in NPM run test.
Now there's a little gotcha.
We cannot just run our tests directly.
I'll tell you why in just a moment.
So we're going to slightly massage that command and change it to npm run test well in S.I.
And that is it.
That's all we're going to do for right now.
Now, the syntax here and understanding what's going on is just a little bit confusing.
This is one of those things where once you see it in action, it really is going to make a lot more
sense.
The changes we have made here.
It's going to make sure that whenever we create updates or re-open a pull request, we are going to
install dependencies into our off project and run this script inside there.
Right now, let's just commit this file.
Let's save it as is.
We're then going to create a new branch inside of our local get repository.
Push it up to this GitHub repo, open a pull request and then just see what happens on the top Right-Hand
side.
I got to find the start commit button and then I'll click on it.
Commit new file.
OK, so we've now created a GitHub action by creating that file and putting a little bit of configuration
in there.
Let's take a pause.
Here we come back the next video.
We're going to make a very small change to our auth project on a branch.
We're then going to commit that do all that stuff.
We just discussed the quick pause.
I'll see you in just a minute.