1
00:00:05,040 --> 00:00:06,610
Well, let's start adapting the pipeline.

2
00:00:07,350 --> 00:00:11,730
The best place to introduce this additional job is in the test stage.

3
00:00:11,970 --> 00:00:18,390
We can also create a, quote, quality stage, but it would be just simpler to test multiple things

4
00:00:18,390 --> 00:00:20,250
in parallel to do the smoke tests.

5
00:00:20,250 --> 00:00:24,900
And also the code quality in parallel with the name of the job will be called quality.

6
00:00:27,590 --> 00:00:29,830
It will be part of the test stage.

7
00:00:32,860 --> 00:00:40,210
And because you are using Gradle, we have to use a docker image that already comes with JDK, so we

8
00:00:40,210 --> 00:00:43,240
are going to use open dedicate as you have used in the smoke test.

9
00:00:46,280 --> 00:00:50,570
And this group that we are going to run is the same script that we have used locally.

10
00:00:54,870 --> 00:01:01,110
I'm going to simply copy and paste the command that has worked locally and put it inside a script.

11
00:01:02,600 --> 00:01:07,520
Finally, as you remember from the console itself, we do not get a lot of information regarding what

12
00:01:07,520 --> 00:01:11,790
went wrong and need access to this e-mail report by default.

13
00:01:11,810 --> 00:01:17,180
This will not be saved anywhere so that we can take a look at what this means is that the job will fail

14
00:01:17,360 --> 00:01:20,480
and we'll have no idea from let's what has happened.

15
00:01:20,810 --> 00:01:26,360
We have, of course, the possibility of running, again, PMed locally and to generate a report locally.

16
00:01:26,780 --> 00:01:31,790
But it will be so much easier to take a look inside and to tell what has gone wrong.

17
00:01:32,480 --> 00:01:35,450
In order to do that, we have to use artifacts.

18
00:01:35,690 --> 00:01:41,960
Now, in this case, artifacts are not only used to save the build itself and to pass it between different

19
00:01:41,960 --> 00:01:46,530
stages, but also anything that we want to keep from the built.

20
00:01:46,730 --> 00:01:52,400
Now, in this case, if the pipeline fails, the artifact, the jar file that we have generated is not

21
00:01:52,400 --> 00:01:53,140
so interesting.

22
00:01:53,150 --> 00:01:58,850
We are interested in the reports, the test reports, the code quality reports, any reports that can

23
00:01:58,850 --> 00:02:00,540
tell us why the buildings failed.

24
00:02:00,890 --> 00:02:03,530
So let's go ahead and define the artifacts.

25
00:02:05,660 --> 00:02:12,470
The part of the artifact will be quite simple, it will be inbuilt, reports PMed, you can easily tell

26
00:02:12,470 --> 00:02:18,800
that locally if you go to build reports PMed, you will see here everything that has been generated

27
00:02:19,250 --> 00:02:20,720
or simply copied above.

28
00:02:21,200 --> 00:02:23,930
And this will ensure that you do not make any typos.

29
00:02:26,780 --> 00:02:33,420
The way artifacts work is that when the job fails by default, the artifacts will not be safe.

30
00:02:33,830 --> 00:02:39,950
But this is exactly what we are interested in if the job feels we want to take a look at the artifact.

31
00:02:40,220 --> 00:02:42,340
So we need to introduce an additional condition.

32
00:02:42,530 --> 00:02:46,820
And this condition is when and we're going to tell it.

33
00:02:46,830 --> 00:02:54,890
Lecci always now always means that these artifacts will be saved always if the code quality is successful

34
00:02:55,040 --> 00:03:00,730
and if the quality feels we are especially interested in, if it fails, what we're going to set it

35
00:03:00,740 --> 00:03:04,070
to always just to make sure that we always have this artifact.

36
00:03:05,050 --> 00:03:09,130
That's about it, this is how the code quality stage would look like when using PMed.