Well, let's start adapting the pipeline.
The best place to introduce this additional job is in the test stage.
We can also create a, quote, quality stage, but it would be just simpler to test multiple things
in parallel to do the smoke tests.
And also the code quality in parallel with the name of the job will be called quality.
It will be part of the test stage.
And because you are using Gradle, we have to use a docker image that already comes with JDK, so we
are going to use open dedicate as you have used in the smoke test.
And this group that we are going to run is the same script that we have used locally.
I'm going to simply copy and paste the command that has worked locally and put it inside a script.
Finally, as you remember from the console itself, we do not get a lot of information regarding what
went wrong and need access to this e-mail report by default.
This will not be saved anywhere so that we can take a look at what this means is that the job will fail
and we'll have no idea from let's what has happened.
We have, of course, the possibility of running, again, PMed locally and to generate a report locally.
But it will be so much easier to take a look inside and to tell what has gone wrong.
In order to do that, we have to use artifacts.
Now, in this case, artifacts are not only used to save the build itself and to pass it between different
stages, but also anything that we want to keep from the built.
Now, in this case, if the pipeline fails, the artifact, the jar file that we have generated is not
so interesting.
We are interested in the reports, the test reports, the code quality reports, any reports that can
tell us why the buildings failed.
So let's go ahead and define the artifacts.
The part of the artifact will be quite simple, it will be inbuilt, reports PMed, you can easily tell
that locally if you go to build reports PMed, you will see here everything that has been generated
or simply copied above.
And this will ensure that you do not make any typos.
The way artifacts work is that when the job fails by default, the artifacts will not be safe.
But this is exactly what we are interested in if the job feels we want to take a look at the artifact.
So we need to introduce an additional condition.
And this condition is when and we're going to tell it.
Lecci always now always means that these artifacts will be saved always if the code quality is successful
and if the quality feels we are especially interested in, if it fails, what we're going to set it
to always just to make sure that we always have this artifact.
That's about it, this is how the code quality stage would look like when using PMed.