1
00:00:00,980 --> 00:00:06,420
This lecture will have a look at adding a test stage to our pipeline in order to test a bit of what

2
00:00:06,420 --> 00:00:10,950
we have previously built to make sure that what we have is actually what we want to have.

3
00:00:12,000 --> 00:00:17,250
In the first question generally is that what makes good lecci jobs fail?

4
00:00:17,610 --> 00:00:23,400
Why is the pipeline all of the sudden failed and doesn't continue with the next steps?

5
00:00:24,060 --> 00:00:25,290
So it goes more or less like this.

6
00:00:25,470 --> 00:00:31,830
Every time a command is executed, it will return something and by convention it will return zero on

7
00:00:31,830 --> 00:00:38,730
success and it will return an integer in the range of one to 255 on error.

8
00:00:39,300 --> 00:00:46,470
So every time Ghilarducci gets a status that is not zero, which means success, it means that something

9
00:00:46,470 --> 00:00:55,470
failed and the command can return a status code in that direction if it hasn't been properly called,

10
00:00:55,470 --> 00:01:00,900
if it's missing parameters or if a certain assertion is in the way it should have been.

11
00:01:02,520 --> 00:01:10,440
So this is why we can rely on the status code of the commands in order to write small tests directly

12
00:01:10,440 --> 00:01:13,800
from the script without relying on any other third party frameworks.

13
00:01:14,520 --> 00:01:20,400
Now, ideally, you are building something and you are running a test.

14
00:01:20,700 --> 00:01:26,510
You are running everything that is needed in terms of testing to make sure that what you have build

15
00:01:26,790 --> 00:01:29,490
is something that you want to deploy later.

16
00:01:30,000 --> 00:01:36,030
But in the simple example, we are going to look on very, very basic tests to demonstrate how this

17
00:01:36,210 --> 00:01:38,370
stage can look like and what we can do.

18
00:01:38,940 --> 00:01:45,150
And let's imagine, for example, we want to test if the files have been properly generated.

19
00:01:45,750 --> 00:01:52,170
And one idea would be to test to index that HTML5 to see if it contains a specific string.

20
00:01:54,350 --> 00:02:00,890
And now inside the public folder and I'll be using grep in order to search for a specific string inside

21
00:02:00,890 --> 00:02:01,310
a file.

22
00:02:02,330 --> 00:02:04,760
So let's search, for example, for Gatsby.

23
00:02:08,610 --> 00:02:16,830
And a file that we are searching into is in the index, that HTML, you'll see here that it has written

24
00:02:16,830 --> 00:02:19,060
the entire string where Gatsby is being found.

25
00:02:19,560 --> 00:02:21,120
You will see it even marked here.

26
00:02:22,260 --> 00:02:24,550
So this was a success.

27
00:02:25,650 --> 00:02:31,020
Now, in case you're unsure about the status code or what has been returned by grep, especially if

28
00:02:31,020 --> 00:02:34,770
you're using grep in a quiet mode, which doesn't give you any output.

29
00:02:36,260 --> 00:02:37,900
You are a bit unsure.

30
00:02:38,070 --> 00:02:39,550
Does this work or not?

31
00:02:39,930 --> 00:02:46,470
So what we can do for debugging purposes and to understand how exactly turncoats who work like is to

32
00:02:46,470 --> 00:02:53,580
simply echo and using a dollar sign and a question mark, you will get the last return code.

33
00:02:55,010 --> 00:03:00,230
So with this case is zero, so let's search for something that definitely doesn't exist.

34
00:03:03,870 --> 00:03:09,480
You'll notice here that my terminal is a bit intelligent and directly gives me the return code here,

35
00:03:09,600 --> 00:03:14,610
but in case yours isn't that, you will see that this has returned one.

36
00:03:15,660 --> 00:03:22,530
And this is a simple command that we can use inside Gottleib in order to make our build fail if something

37
00:03:22,530 --> 00:03:23,140
doesn't work.

38
00:03:24,570 --> 00:03:26,760
So let's go ahead and add this additional job.

39
00:03:28,070 --> 00:03:29,900
And call it test artifact.

40
00:03:36,000 --> 00:03:36,930
And the script.

41
00:03:40,390 --> 00:03:41,500
Would be quite simple.

42
00:03:43,210 --> 00:03:44,170
I'm going to grep.

43
00:03:45,970 --> 00:03:46,930
Forget be.

44
00:03:51,420 --> 00:03:55,200
Inside the index, that e-mail file inside a public folder.

45
00:04:02,760 --> 00:04:05,310
Let's go ahead and define the stages that we have.

46
00:04:09,240 --> 00:04:10,680
We'll will have to build stage.

47
00:04:11,790 --> 00:04:13,470
And we'll have to test stage.

48
00:04:16,839 --> 00:04:21,610
The way you name your stages and the way you name your builds is totally up to you.

49
00:04:22,720 --> 00:04:27,300
You can simply call this build and the stage will be built.

50
00:04:27,310 --> 00:04:28,600
So there's absolutely no problem.

51
00:04:28,620 --> 00:04:29,920
They don't have to be different.

52
00:04:30,190 --> 00:04:34,230
You just need to specify which job belongs to which stage.

53
00:04:40,670 --> 00:04:42,410
And this will be stage death.

54
00:04:46,660 --> 00:04:51,650
I think is generally a good idea to test whatever you're doing to make sure it fails as well.

55
00:04:52,240 --> 00:04:58,810
So I'm going to add here something that will succeed and something that will fail, just to have assertions,

56
00:04:58,810 --> 00:05:03,550
just to have tests that actually work and just don't give us the feeling that something is working but

57
00:05:03,550 --> 00:05:04,370
actually doesn't work.

58
00:05:04,390 --> 00:05:06,460
So is this what you are you're doing?

59
00:05:06,460 --> 00:05:11,590
Just don't assume that something will automatically work just because the command looks right.

60
00:05:12,160 --> 00:05:13,090
OK, I think we're good.

61
00:05:13,090 --> 00:05:15,310
Let's committees and see how the pipeline looks like.

62
00:05:16,720 --> 00:05:20,740
Now, if you look at our pipeline, you will see that we now have two stages.

63
00:05:22,430 --> 00:05:25,590
And we already know that first they will be successful.

64
00:05:25,610 --> 00:05:32,330
So what we're interested in is seeing the second part of the stage at that stage, but we'll wait a

65
00:05:32,330 --> 00:05:32,890
bit for that.

66
00:05:34,250 --> 00:05:37,070
The first stage is completed and now the test has started.

67
00:05:37,110 --> 00:05:38,800
So let's take a look at this.

68
00:05:39,300 --> 00:05:46,730
You'll notice that in this job, because we haven't specified an image, it will default to the image

69
00:05:46,730 --> 00:05:52,150
that the Getler Brunner is providing in this case, Ruby, and will look a bit later on.

70
00:05:52,150 --> 00:05:54,670
Now, we can replace that as well with a different image.

71
00:05:56,580 --> 00:06:02,550
So this is the output of the test, the test has been successful and the first command succeeded and

72
00:06:02,550 --> 00:06:05,610
the second one we have now the exit code one.

73
00:06:07,480 --> 00:06:13,570
So everything looks good at this moment and in this way, we have now managed to at this stage that

74
00:06:13,570 --> 00:06:20,040
proves that what we have previously build is at least the very minimalistic level, the right thing.

75
00:06:20,050 --> 00:06:22,720
It it contains what we expect it to contain.