1
00:00:03,850 --> 00:00:09,280
Now, we have created this artifact, but how exactly do we know if this actually works?

2
00:00:09,880 --> 00:00:15,210
Because locally we could build and start the application and easily see if it's working.

3
00:00:15,640 --> 00:00:19,350
But in Vietnam, we haven't written any test.

4
00:00:19,780 --> 00:00:24,550
So what we're trying to do next is to create a simple smoke test.

5
00:00:25,690 --> 00:00:29,140
This doesn't mean that we want to keep this smoke test forever.

6
00:00:29,410 --> 00:00:34,180
But now, initially, we don't have any other tests and we simply want to check if it works, if the

7
00:00:34,180 --> 00:00:35,080
application works.

8
00:00:35,650 --> 00:00:36,940
So what is a smoke test?

9
00:00:37,270 --> 00:00:41,740
To put it very simple, is a very, very simple test to check if something works.

10
00:00:42,010 --> 00:00:45,640
It doesn't go into detail to see if all the bits and pieces work.

11
00:00:46,030 --> 00:00:51,550
But just if you compare it like if you're responsible to testing a computer, you will only boost the

12
00:00:51,550 --> 00:00:55,050
power button to see if the screen turns on and if something happens.

13
00:00:55,060 --> 00:00:57,640
So it is a very, very basic test.

14
00:00:58,140 --> 00:00:58,810
In this case.

15
00:00:58,810 --> 00:01:04,540
We are going to start the application in a pretty similar way as we did locally and to make sure that

16
00:01:04,540 --> 00:01:04,970
it works.

17
00:01:05,000 --> 00:01:09,550
So I'm going to call an end point and we're going to use Carl for that to see if the application response

18
00:01:09,970 --> 00:01:11,880
and that will be enough for this smoke test.

19
00:01:12,340 --> 00:01:14,050
It doesn't mean that the database works.

20
00:01:14,060 --> 00:01:15,700
It doesn't mean that everything works.

21
00:01:15,700 --> 00:01:21,670
But just in case there's like an obvious error with application, this smoke test will be able to tell,

22
00:01:21,760 --> 00:01:24,430
hey, this application doesn't respond at all.

23
00:01:24,710 --> 00:01:25,660
Something is broken.

24
00:01:27,710 --> 00:01:31,760
So at this time, we're going to add a new stage, I'm going to call this The two-Stage.

25
00:01:34,140 --> 00:01:37,410
And we're also going to add a smoke test job.

26
00:01:40,580 --> 00:01:43,640
It will be part of the best state.

27
00:01:44,620 --> 00:01:47,950
And we will use this exact same image as we have used above.

28
00:01:51,370 --> 00:01:52,600
I'm going to need a script.

29
00:01:53,710 --> 00:01:56,050
What am I going to do is I'm going to use Chavo.

30
00:01:58,130 --> 00:02:05,240
They're going to specify the artifact that we have created, which is available in built Lipps.

31
00:02:08,500 --> 00:02:10,780
Stosz Apiata Dark.

32
00:02:12,060 --> 00:02:16,680
What this will do is it's going to use this jar file to run this application.

33
00:02:17,190 --> 00:02:19,730
We actually want this application to run in the background.

34
00:02:19,740 --> 00:02:26,160
So for that reason, we have to use this additional comment here to tell this command to run the background.

35
00:02:27,160 --> 00:02:32,740
Now, because this Java process, in order to start our application, takes a few seconds to run until

36
00:02:32,740 --> 00:02:38,500
the server is actually running the application, we're going to end here asleep for 30 seconds.

37
00:02:40,530 --> 00:02:46,140
That should give it enough time to be ready, otherwise, if we don't do this, we will try the next

38
00:02:46,140 --> 00:02:51,570
command, which is Kerl, to access an end point and then Carl will fail because the application is

39
00:02:51,570 --> 00:02:52,010
not ready.

40
00:02:52,020 --> 00:02:58,620
It is not the best practice to put sleep inside your pipelines because they will run slower.

41
00:02:58,950 --> 00:03:03,930
But in this case, we just wanted to create a smoke test and we're going to replace it later with something

42
00:03:03,930 --> 00:03:04,280
better.

43
00:03:05,410 --> 00:03:09,190
Next, we want to call an end point that the publication provides.

44
00:03:11,020 --> 00:03:16,480
We're back to the Postman collection, remember that we had this have end point and isn't able to ask

45
00:03:16,480 --> 00:03:18,340
to check for the status up.

46
00:03:19,030 --> 00:03:26,050
So if this end point says the application is up, we're more than happy to continue and see the smoke

47
00:03:26,050 --> 00:03:26,950
test has passed.

48
00:03:27,430 --> 00:03:28,830
The application says it's up.

49
00:03:28,840 --> 00:03:30,040
It's probably up.

50
00:03:30,040 --> 00:03:34,480
We're not going to check if we can get cast or add cast or something like that.

51
00:03:34,750 --> 00:03:36,780
So we want to keep it very, very simple at this point.

52
00:03:38,720 --> 00:03:44,030
This would be the base you are all that you can use for localhost on board five thousand and this is

53
00:03:44,030 --> 00:03:44,650
the end point.

54
00:03:56,830 --> 00:04:04,660
Additionally, we want to search for up, I'm going to use GRAP and remember, Greb allows us to search

55
00:04:04,660 --> 00:04:09,040
in the response for a specific string and if it finds it, the return code will be zero.

56
00:04:09,190 --> 00:04:11,670
And if it doesn't find it, the return card will be one.

57
00:04:11,680 --> 00:04:17,620
So that's pretty easy visually because this is an Alpine image doesn't come with Kerl.

58
00:04:18,070 --> 00:04:21,720
So for that reason, before we can use code, we actually have to install Kearl.

59
00:04:22,630 --> 00:04:28,870
It is a good practice to add anything that's not directly related to the script itself, to the before

60
00:04:28,870 --> 00:04:29,410
script.

61
00:04:31,360 --> 00:04:37,120
In practice, both at same time will be practically put together, so it doesn't make any difference,

62
00:04:37,420 --> 00:04:43,480
but it makes it clear that in the before script is everything that is necessary for the script to run.

63
00:04:49,970 --> 00:04:56,540
So it seems that we now have everything in place, we have a build step and we have a basic smoke test

64
00:04:56,600 --> 00:04:57,110
step.

65
00:04:57,920 --> 00:05:02,780
Because the Built-up step already has published, the artifacts there will be automatically downloaded

66
00:05:02,780 --> 00:05:03,860
by the smoke test.

67
00:05:04,870 --> 00:05:06,790
So let's see the pipeline and see how it works.

68
00:05:08,150 --> 00:05:12,290
There are still a small typo here, it needs to be Caras API.

69
00:05:23,950 --> 00:05:30,840
Now, the job that's interesting for us is the smoke test job, and you can see this has completed successfully.

70
00:05:31,870 --> 00:05:34,780
This is where we have started our application in the background.

71
00:05:36,070 --> 00:05:43,270
And we waited for 30 seconds, and you can see here the application is trying to start the spring application

72
00:05:43,360 --> 00:05:48,490
and this is like the console that's being generated when you start the application initially.

73
00:05:49,070 --> 00:05:52,270
And after that, it says that an application in 13 seconds.

74
00:05:52,760 --> 00:05:59,770
So this can be a very good idea to look at these logs and to see how much it does take to start the

75
00:05:59,770 --> 00:06:00,430
applications.

76
00:06:00,460 --> 00:06:02,560
For example, now 30 seconds, maybe too much.

77
00:06:02,740 --> 00:06:04,930
We can reduce that to 20 seconds if we want.

78
00:06:05,840 --> 00:06:11,750
And after that, we started the colonel command and we have looked for up, you can see here the response

79
00:06:11,750 --> 00:06:13,010
and said status up.

80
00:06:13,460 --> 00:06:16,940
So because the response contained up, this job succeeded.

81
00:06:17,420 --> 00:06:20,150
So now we have a very simple smoke test.

82
00:06:20,270 --> 00:06:25,730
But this smoke test ensures that our application at least has been built correctly.

83
00:06:25,730 --> 00:06:26,720
And it starts.