Now, let's continue with our testing strategy and make some optimizations will now remove.
This command, because we don't want our test to fail, we actually want them to succeed and will adequate
flag rescue in order not to have this large output of data in our logs from Gottleib, which is definitely
not interesting for us.
As previously mentioned at the test, artifact now is using the previous default image from Dukkha.
And we can leave it that way or we can specify our own image.
There's an index distribution out there that is very, very minimal, is only five megabytes in size
and it's quite fast.
It's called Alpine.
And let's give it a try out for this job to see if the job succeeds using this much smaller image.
Now, in order to test this artifact, we do not need Noad installed or anything else, so for that
reason, we can simply try out this image and see if at least this utility grap is installed, because
this is the only thing that we actually need.
Additionally, let's go ahead and add another job gets worse as the possibility of starting a server.
And when you're starting a server, we can use HTP in order to access the website and to see how it
looks like.
So this can look like the following.
So let's call this test website.
Uh.
And will add this to the stage as well, and you will later see what this has for an effect.
And now let's see what we need in order to be able to start this.
So we are going to use Gatsby's serve and this will start the server using the production build that
we have previously generated.
Now, in order for Gatsby to run, we still need a couple of steps.
So we still need NPM install and we still need to install to special.
Otherwise, this will not work.
And additionally, we need to following.
We want to use Carl, and this is used for fetching resources.
And the resource that we are actually fetching is the local website, so Gatsby CERV will start a server,
it will be available on localhost, usually import nine thousand.
So let's see how that can look like.
So Carol will basically download the website, will download the contents of this website, and we can
use what we have previously used, we can simply grep or destroying and.
When using commands, we can use the pipe operator so the output from downloading the website will be
piped through will be given as an input for the grep command.
So we do not have to specify the file that we want to search for a string.
So this is the to download the website is the input and is giving it to grep.
And if grep fails, then this will fail as well.
There's one more thing that I need to do, I need to specify the image we still need not for this.
And after this, let's give it a try and see how it looks like.
One of the first things that you will notice if you're now looking at this new pipeline is that we have
two jobs running in parallel.
And this is because we have created the test artifact job and a test website job and we have assigned
them to the same stage name test.
And when we do that, we actually are telling it, Lappe, that it should run this jobs in parallel.
Now, in this specific case, running the job in parallel will probably not make the job run faster
because it will have the overhead of downloading the Docker image.
But there are scenarios when it definitely does make sense to run different tests in parallel, because
if their execution is long enough and you run different tests in parallel, then altogether there will
be much faster and your pipeline as a whole would be much faster.
If you're interested in sort of optimizing your process, then this is a good idea.
I have to say that not every job can be paralyzed.
And if especially if they are dependencies between two jobs, you cannot do it.
So, for example, we cannot run the bill step and a test step in parallel because the in order to test
the artifact, we first have to build the artifact.
So if there are any dependencies between the jobs, then we we cannot do that.
But as we have it in this scenario, we are building the website that doesn't have the artifact and
then we're doing something with the artifact.
The one job is simply testing its output, testing some files and the other one starting a server and
doing something.
Then we have no problem with that, that that is definitely possible.
And you will see now the club is executing both jobs in the test stage in parallel, and the first one
is actually done.
And you will see that it was quite fast.
So using the Alpine image was definitely worth it, because we have executed the entire job in only
20 seconds and that is absolutely amazing.