Narrator: In the last section,
we set up some integration between Travis CI and GitHub.
Now, anytime that we push our code up to GitHub,
Travis CI is gonna get a little tap on the shoulder
and we're told, hey, this person just pushed some new code,
download the code and do some amount of work on it.
Now the real question is,
what is Travis going to do with our code base?
Well, Travis is not going to just automatically or
magically figure out what to do,
we have to be very explicit, very clear with Travis CI
and say, here is exactly what we want you to do.
We want you to test our code and then if all the tests pass,
we want you to deploy our project over to AWS.
For right now, we're just gonna focus
on getting everything set up for running our tests.
We're not gonna worry about the AWS deployment just yet.
So even with running our tests
we have to give Travis a little bit of direction,
meaning we have to tell it how to
essentially start up Docker, how to run our test suite
and how to interpret the results.
In order to do so we're gonna create a file called,
the Travis-dot-YAML file, and we're going to put that
into our route project directory.
The Travis-dot-YAML file
is gonna have the series of directions
to tell Travis exactly what we want it to do.
Now I put together a little diagram
to outline the different steps
that we're gonna put into that file.
So here's what we need to do
inside the Travis-dot-YAML file.
First off, we're gonna tell Travis
that we need to have a copy of Docker running.
Our entire project relies upon Docker.
We need the Docker CLI to build an image
and to create a container out that image.
And so definitely as soon as Travis pulls down
our entire repository, we need to have a copy of Docker
waiting to go or ready to go,
ready for us to run a couple commands to build our image
and then run our test suite.
So after we tell Docker--
Or excuse me, after we tell Travis
that we need a copy of Docker,
we'll then write a little bit of configuration
to tell Travis to build our image
using the docker-file-dot-dev file.
Now, that might be a little bit surprising,
the fact that I'm saying we're going to use
docker-file-dot-dev.
Well, quick reminder here,
the entire purpose of Travis is to first run our test suite.
We put together the Docker file
like that production Docker file, just a moment ago.
This one right here is specifically used
when we want to create a container
that is going to be used in production,
running on some server ready for users to come and visit.
The image that is created by this Docker file
has no dependencies or any code inside of it
meant for running our test suite.
If we want to run our test suite,
we have to use the docker-file-dot-dev file instead.
So that's exactly what we're going to do.
We're gonna make sure that we build an image
using the docker-file-dot-dev file.
After we build the image, we'll then tell Travis
how to run our test suite.
Essentially, we're gonna say,
hey, to run our test suite execute Docker run,
our image and pmrun test.
That's pretty much it.
Then at some point in time in the future,
we're gonna come back
and make sure that we also tell Travis
how to deploy our project over to AWS.
But again, we're not gonna do that just yet.
Just to make sure that's clear, I'll put that in yellow.
So for right now, we're just focused
on getting our test to run on Travis.
So let's get to it.
I'm gonna flip back over to my code editor
and in my route project directory,
I'm gonna make a new file called,
dot-travis-dot-yml, like so.
Now really important here,
please, please, please make sure you get that leading dot,
it's dot-travis-dot-yaml.
If you don't have that leading dot right there,
we're gonna run into some issues later on.
Okay, so now inside of here,
we're gonna start writing out some configuration
for these three steps.
Now, the configuration that we're gonna put in here,
we're gonna go over rather quickly, just because this is
not quite so much a course about Travis,
it's supposed to be about Docker, so
I'll give you some brief explanation
about each of the steps.
The first thing we're gonna do is say pseudo required.
Anytime that we're making use of Docker,
we have to have superuser permissions.
And so pseudo required says,
hey Travis we need superuser level permissions
in order to execute this build.
The next thing we're gonna do
is make sure that Travis CI
understands that we need the Docker CLI pre-installed.
So we'll say, services and then list out Docker, like so.
By adding this in ,
Travis CI is going to automatically install a copy of Docker
into our little running container.
Well, I don't really wanna get into
what Travis does behind the scenes
but essentially this is gonna say,
hey Travis CI, we need a copy of Docker ready to go.
After that, we'll define another section called,
before install.
Before install right here,
is going to have a series of different commands
that get executed before our tests are ran.
And so you can imagine, anything that we list right here,
as being some series of steps
or some series of setup that needs to occur
before we start to either deploy our project
or before we start to run our tests.
And so for you and I, we want to attempt to
build our Docker image before the tests run.
So I'm gonna put in a little dash
and then we'll write out the command
that should be executed to build our Docker image.
So we'll say, Docker build.
We're gonna make sure that we force this thing
to use the docker-file-dot-dev file.
So I'll say dash-f, docker-file-dot-dev.
And then we'll set the build context by putting a dot in,
which remember, essentially means use the current directory
when figuring out what to do.
Now, one last quick thing here.
Remember, anytime that we run Docker file--
Or excuse me, Docker build,
we get back the ID of the image that is created.
Throughout this course we've been copy pasting
that idea around, but you can imagine
that when we start doing this stuff with Travis CI,
we don't really get the ability to easily copy paste
those IDs around.
We're not involved in this process one bit.
These are all automated commands
that are going to be executed on our behalf.
So in order to avoid having to juggle that idea around
and copy paste it to the next command,
we'll instead just put a tag or a label of sorts
on the image that is created.
So we can refer to the image that is created by a name
rather than a randomly generated ID.
So to tag this thing, I'll say, dash-T.
Then my Docker username, which is Steven Greider.
Again, that's my Docker username.
And I'll say, dash,
and I'll put in the name other repository
that we are building from here, docker-dash-react.
So docker-dash-react.
So now in the future,
we could refer to the image that is created by saying,
Steven Greider-slash-docker-slash-react
or whatever your username is.
Now, one thing to be aware of here,
we do not have to tag this thing with this really long,
very formal tag.
We could just as easily say, my--
Oops, we just as easily say, my image
or test me or something like that.
Because the tag that is being applied here
is only going to be used inside of this,
essentially Travis process.
Not gonna be used anywhere else.
So you can use any tag you want there,
but it is good convention to use the real convention here,
which is the Docker username
and then the repository name after it.
Okay, so this is looking pretty good.
Let's take a quick pause right here.
When we come back the next section,
we're gonna start to tell Travis how to run our test suite
and then we'll try doing a test deploy this
and make sure that everything works as expected.
So I'm gonna save this file and we'll do a quick break
and I'll see you in just a minute.