This lecture will have a look at adding a test stage to our pipeline in order to test a bit of what
we have previously built to make sure that what we have is actually what we want to have.
In the first question generally is that what makes good lecci jobs fail?
Why is the pipeline all of the sudden failed and doesn't continue with the next steps?
So it goes more or less like this.
Every time a command is executed, it will return something and by convention it will return zero on
success and it will return an integer in the range of one to 255 on error.
So every time Ghilarducci gets a status that is not zero, which means success, it means that something
failed and the command can return a status code in that direction if it hasn't been properly called,
if it's missing parameters or if a certain assertion is in the way it should have been.
So this is why we can rely on the status code of the commands in order to write small tests directly
from the script without relying on any other third party frameworks.
Now, ideally, you are building something and you are running a test.
You are running everything that is needed in terms of testing to make sure that what you have build
is something that you want to deploy later.
But in the simple example, we are going to look on very, very basic tests to demonstrate how this
stage can look like and what we can do.
And let's imagine, for example, we want to test if the files have been properly generated.
And one idea would be to test to index that HTML5 to see if it contains a specific string.
And now inside the public folder and I'll be using grep in order to search for a specific string inside
a file.
So let's search, for example, for Gatsby.
And a file that we are searching into is in the index, that HTML, you'll see here that it has written
the entire string where Gatsby is being found.
You will see it even marked here.
So this was a success.
Now, in case you're unsure about the status code or what has been returned by grep, especially if
you're using grep in a quiet mode, which doesn't give you any output.
You are a bit unsure.
Does this work or not?
So what we can do for debugging purposes and to understand how exactly turncoats who work like is to
simply echo and using a dollar sign and a question mark, you will get the last return code.
So with this case is zero, so let's search for something that definitely doesn't exist.
You'll notice here that my terminal is a bit intelligent and directly gives me the return code here,
but in case yours isn't that, you will see that this has returned one.
And this is a simple command that we can use inside Gottleib in order to make our build fail if something
doesn't work.
So let's go ahead and add this additional job.
And call it test artifact.
And the script.
Would be quite simple.
I'm going to grep.
Forget be.
Inside the index, that e-mail file inside a public folder.
Let's go ahead and define the stages that we have.
We'll will have to build stage.
And we'll have to test stage.
The way you name your stages and the way you name your builds is totally up to you.
You can simply call this build and the stage will be built.
So there's absolutely no problem.
They don't have to be different.
You just need to specify which job belongs to which stage.
And this will be stage death.
I think is generally a good idea to test whatever you're doing to make sure it fails as well.
So I'm going to add here something that will succeed and something that will fail, just to have assertions,
just to have tests that actually work and just don't give us the feeling that something is working but
actually doesn't work.
So is this what you are you're doing?
Just don't assume that something will automatically work just because the command looks right.
OK, I think we're good.
Let's committees and see how the pipeline looks like.
Now, if you look at our pipeline, you will see that we now have two stages.
And we already know that first they will be successful.
So what we're interested in is seeing the second part of the stage at that stage, but we'll wait a
bit for that.
The first stage is completed and now the test has started.
So let's take a look at this.
You'll notice that in this job, because we haven't specified an image, it will default to the image
that the Getler Brunner is providing in this case, Ruby, and will look a bit later on.
Now, we can replace that as well with a different image.
So this is the output of the test, the test has been successful and the first command succeeded and
the second one we have now the exit code one.
So everything looks good at this moment and in this way, we have now managed to at this stage that
proves that what we have previously build is at least the very minimalistic level, the right thing.
It it contains what we expect it to contain.