-: In the last section,
we put together the production version of our Docker file
for the client project.
Now that we've got production versions
and we've essentially productionized
I guess is the best term all these sub-projects,
we're now gonna start to work on the Travis dot yml file,
which is going to instruct Travis
on exactly how to handle our build
when we push our code up to GitHub.
I put together a couple of steps
of what we're going to do inside the Travis file.
Now in general, all the configuration
that's gonna go inside of here is gonna look very similar
to the last Travis dot yml file we put together.
So at the top of the Travis dot yml file,
we're gonna specify Docker as a dependency.
We're then going to build a test version
of the React Project,
cause remember part of the entire purpose of Travis CI
is to run some number of tests.
So we're going to build out the React project
using the development Docker file,
because only the development Docker file
has all the source code required for running our tests.
We'll run the tests
and then as long as the tests are successful,
we'll build production versions of all the sub-projects,
we'll push them off to Docker hub
and then we'll tell Elastic Beanstalk to update.
Now quick reminder, we have not yet created an instance
of Elastic Beanstalk.
So at this point we're just gonna do kind of like
half of the Travis dot yml file
and then we're going to flip over to Elastic Beanstalk
and make sure that we have an environment ready for us.
Now one other quick thing I wanna mention here,
this quick note,
we are only going to be running tests
around the React project.
If you had other tests for say the server
or the worker projects,
we could very easily expand the Travis dot yml file
to build out the test versions of images
for the server and the worker
and run tests inside of those images or those containers
at the same time as well.
So even though we're only doing tests for the React project
it would be very easy, very straightforward
to add in other test suites to this entire process as well.
Okay, so with all this in mind, let's get to it.
I'll flip back over to my code editor,
inside of my route project directory,
I'll make a new file called, dot Travis dot yml.
Again, remember, we have a leading dot on here.
Please don't forget the leading dot.
And then inside of here we'll put down
a little bit of configuration that looks very similar
to what we did previously.
So I'll say pseudo is required,
for services we want to get access to a copy of Docker
and then as a before install step,
we're going to build a test version of our client project
and then eventually run some tests inside of it.
So remember to build out a test version
of the client project,
we'll make an image out of the docker file dot dev file.
Again, we're making use of the development Docker file here,
because we only get access to all these test suites
and all that kind of good stuff
when we have all of the dependencies
attached to the project.
The production Docker file installs dependencies,
builds a production version of the project
and then copies over just the very raw production version
of our assets
and so that's why we're not gonna use
the production Docker file.
Production Docker file does not allow us to run any tests.
Okay, so we'll say dash Docker, build,
we'll tag the image with your Docker I.D.
and then some name for this image, I'll call it React test,
that works just fine.
And now this time around we do have to specify
or override the default Docker file.
So I'll say dash F.
Now this time, remember our Travis dot yml file
is in the root project directory,
but we want to specify a Docker file
that exists inside the client directory.
So we have to provide a relative path
to the client Docker file dot dev file.
So I will say dash F dot slash client
Docker file dot dev, like so
and I'll zoom out just so you can see that whole line.
And then after that, we still need to also specify
the build context where essentially
where all of our project files for the image can be found.
We've always been doing dot before,
because we always wanted to use the current
working directory as essentially the build context,
but again, this time around we wanna specify
this nested folder of client as our build context.
So rather than just specifying dot as the build context,
I'll say dot slash client,
which means look into the client directory
to get the build context.
Okay, so that's it for the before install step.
So after we've built out that image
we then need to use it to run a couple of tests.
So I'll specify the script section.
Remember the script section
is the primary test running section.
If any of the scripts that we add inside of here
exit with a status code other than zero
then Travis CI is going to assume that our build failed.
So if you had other, like I just said a moment ago,
if you had other projects or other sub-projects
or images in here that you wanted to run tests for,
you could add in an additional
build install script right here
to essentially Docker build my other project.
And then on the script section you would do a Docker run,
my other project and then you would override
the default startup command with run my tests
or whatever it might be.
Again, you can add in
as many scripts right here as you want to
for running your test suites.
But in our case, we want to run a very specific script.
We want to do Docker run,
we want to use the image that we just created,
so it'll be your Docker I.D. slash React test
and then we will override the default startup command
with NPM test.
And remember how by default NPM test enters watch mode,
which means it's never going to exit
and so we're gonna make sure that this thing
eventually exits by adding on dash dash space,
dash dash coverage like so.
So that's going to make sure that the test script
eventually exits with a status code of either zero
or not zero if the test failed.
Okay, so this looks pretty good.
So after we run the script
and after everything passes successfully,
we'll then add on a after success block right here.
Inside of the after success block
we're gonna start to add in the configuration
that's going to build the production version
of all of our projects and then push them off to Docker Hub.
So let's first begin by doing the production version
of each of our different sub=projects in here.
So we need to do a docker build for the client,
NGINX server and worker folders.
So I will do a Docker build, dash T, Stephen Grider
and then we're going to give a very real
image name to this one, so it has my image names,
like I'm gonna use kind of a consistent scheme here.
I'm gonna call each of these multi
and then the name of the project,
so like multi dash client.
I'm using the word multi right here
just because this is a multi container project.
In general you can call the image whatever you want
for the repository name,
but again I'm going to use multi dash
and then the name of the sub-project over here
just to stay a little bit consistent.
And then as the build context
I'll make sure that I pass in, client like so.
Now this time around
we do not have to specify the Docker file,
because it can use the default Docker file
of simply Docker file right there.
Now we're gonna repeat the same process
for all the other directories as well.
So I'll do a docker build dash T,
Stephen Grider multi NGINX,
dot slash NGINX.
I'll do a Docker build multi server, with dot slash server
and then a Docker build dash T, a Stephen Grider
multi worker with the worker folder like so.
So again, this is going to go through
each of these sub folders
and build images using the production Docker file
for each one.
So after we build these production version of the images
we then have to push them all off to Docker Hub.
So at this point we've kind of gone for a long time.
Let's take a quick pause right here.
When we come back to the next section,
we're gonna add on a little bit more code
to make sure that we push off everything to Docker Hub
and then we'll be just about set.
So quick break and I'll see you in just a minute.