1
00:00:04,350 --> 00:00:12,000
Now, if you're looking at a test website job, you will see or you probably figure out that we have

2
00:00:12,000 --> 00:00:14,010
done something kind of weird.

3
00:00:14,880 --> 00:00:17,220
So now we have executed Gatsby serve.

4
00:00:18,820 --> 00:00:25,180
And it's saying that the website is running at a specific address that we actually expected to, but

5
00:00:25,180 --> 00:00:27,970
it seems that the next comment is not being executed.

6
00:00:28,930 --> 00:00:35,410
And this is because get disserve sort of blocks the entire terminal with this execution.

7
00:00:35,410 --> 00:00:38,050
So it will not allow for the next command to start.

8
00:00:38,560 --> 00:00:40,540
And the process is sort of still running.

9
00:00:40,540 --> 00:00:45,310
So it will not give back to possibility for the for the rest of the job to continue.

10
00:00:45,730 --> 00:00:47,920
And this is not exactly what you wanted to do.

11
00:00:47,920 --> 00:00:52,650
And if we leave it in this change, it will more or less run forever?

12
00:00:53,020 --> 00:00:54,340
Well, not actually forever.

13
00:00:54,580 --> 00:00:59,980
If you look here on the right side, you will see that you have the duration of the job.

14
00:00:59,990 --> 00:01:03,140
So how many seconds have passed since the job started?

15
00:01:03,190 --> 00:01:05,470
I'm at three minutes, four minutes almost.

16
00:01:06,220 --> 00:01:12,610
And there's also the information regarding the timeout, not the time means if this job is not responding

17
00:01:12,610 --> 00:01:16,120
after one hour, Gottleib will ultimately kill it.

18
00:01:16,140 --> 00:01:21,280
So if the entire job takes more than one hour, there's something wrong with it.

19
00:01:21,330 --> 00:01:26,200
Generally, it shouldn't take that long, and especially in our case, it should only take a few minutes.

20
00:01:27,010 --> 00:01:32,500
And if you leave it in this stage, as I said, it will run forever, or in this case, it'll run to

21
00:01:32,500 --> 00:01:38,680
the timeout that is configured here at one hour and after one hour gets up will fail this job because

22
00:01:38,680 --> 00:01:40,260
it has run into this timeout.

23
00:01:41,290 --> 00:01:44,590
Now, we don't have to wait one hour to fix our mistake.

24
00:01:44,590 --> 00:01:45,250
In this case.

25
00:01:45,700 --> 00:01:49,750
We can click here on console and we can just terminate the job.

26
00:01:52,480 --> 00:01:58,000
So what we need here in order to sort of release the terminal is to use.

27
00:01:59,370 --> 00:02:09,750
The end sign, the ampersands sign, and what will this do is sort of run this process in in the background

28
00:02:10,050 --> 00:02:12,020
so it will execute this.

29
00:02:12,450 --> 00:02:17,180
The server will continue to run and it will release it for the next comment.

30
00:02:19,420 --> 00:02:24,610
Additionally, what we want to do, because the server takes like a few seconds to start, we want to

31
00:02:24,610 --> 00:02:31,390
include a small pause in our execution and just to give the next command a chance and to give the Gatsby

32
00:02:31,390 --> 00:02:34,570
server a chance to start going to say, here, sleep.

33
00:02:36,350 --> 00:02:41,300
And we are going to indicate a number of seconds, I think three seconds should be more than enough,

34
00:02:42,590 --> 00:02:48,080
and this is not the smartest way to do it, because no matter how fast the server starts, we'll always

35
00:02:48,080 --> 00:02:49,130
wait three seconds.

36
00:02:49,550 --> 00:02:54,770
But for the simple example is definitely more than enough just to exemplify how we can include a small

37
00:02:54,980 --> 00:02:58,900
slip inside a script, but will deal with that a bit later.

38
00:03:01,250 --> 00:03:03,110
So let's committees and see how it looks like.

39
00:03:05,680 --> 00:03:10,660
It is an important thing I want you to notice when you are going to view all the pipelines that are

40
00:03:10,660 --> 00:03:17,890
currently running, this is available in Cassidys pipelines and you will see here that we still have

41
00:03:17,890 --> 00:03:21,190
the previous pipeline running from the previous permit.

42
00:03:22,090 --> 00:03:26,850
And because we have pushed another change, another pipeline was started.

43
00:03:27,190 --> 00:03:29,960
So we now have two pipelines running in parallel.

44
00:03:30,700 --> 00:03:36,700
So I just wanted for you to be aware that there is the possibility that pipelines run in parallel so

45
00:03:36,700 --> 00:03:39,130
they will not be automatically cancelled or something like that.

46
00:03:39,130 --> 00:03:43,060
When the new pipeline starts, you will have pipelines running in parallel.

47
00:03:43,270 --> 00:03:47,260
And especially as this previous pipeline, we don't need it anymore.

48
00:03:47,260 --> 00:03:50,780
We can cancel the job or we can actually cancel the entire pipeline.

49
00:03:51,160 --> 00:03:53,230
It really depends on how you want to do it.

50
00:03:56,550 --> 00:03:58,380
Nine o'clock here, stop the pipeline.

51
00:04:01,850 --> 00:04:04,550
And will see here that the pipeline has been canceled.

52
00:04:07,260 --> 00:04:13,950
You can additionally cancel jobs, so every time you click on a job and you will see here this button,

53
00:04:14,550 --> 00:04:17,250
if I click on it, you can cancel individual stages.

54
00:04:17,260 --> 00:04:22,440
So if you're, like, constantly working on your pipeline and trying to optimize it and at the same

55
00:04:22,440 --> 00:04:27,030
time, you want to sort of save resources or you have the impression that the pipeline altogether is

56
00:04:27,030 --> 00:04:27,810
running a bit slow.

57
00:04:28,260 --> 00:04:32,910
You can definitely cancel jobs that make no sense in continuing to run.

58
00:04:35,090 --> 00:04:42,230
Now, let's take a look at what our test website stage is doing, and you will see that this is still

59
00:04:42,230 --> 00:04:46,990
failing, but at least what we have done here is worked.

60
00:04:47,300 --> 00:04:52,730
So we are serving the website and after this, we are waiting OCF seconds.

61
00:04:54,880 --> 00:05:01,020
And you will see that in parallel, you are still getting outputs from The Gatsby self-command.

62
00:05:01,030 --> 00:05:06,490
So it's saying here Gatsby are running at this address.

63
00:05:07,970 --> 00:05:13,370
Now, the process in figuring out what has happened here is relatively the same.

64
00:05:15,120 --> 00:05:20,030
Generally, what you want to do is to identify where from where this area is coming from.

65
00:05:20,030 --> 00:05:24,980
And obviously it's coming from this comment and we're getting here this Arrowfield writing body.

66
00:05:25,760 --> 00:05:29,600
And the idea would be to search for this specific string.

67
00:05:30,510 --> 00:05:38,160
And to find online help on why this is happening and for example, a quick search leads to stack overflow

68
00:05:38,160 --> 00:05:44,400
with somebody having a similar problem, you will see here that's using Croal and is passing this information

69
00:05:44,400 --> 00:05:45,180
to grep.

70
00:05:46,170 --> 00:05:51,930
And apparently it says that this happens when a program, for example, Greb closes the read pipe before

71
00:05:51,930 --> 00:06:00,870
the previous program is finished, writing the whole page and as a solution is using tech and is saying

72
00:06:00,870 --> 00:06:06,420
that tech is a simple Unix problem that reads the entire input page and reverses the line order.

73
00:06:07,560 --> 00:06:09,330
For that reason, you have to run it twice.

74
00:06:10,140 --> 00:06:13,830
So let's try this and see if this solves our problem.

75
00:06:15,220 --> 00:06:16,560
So I'm going to adhere to.

76
00:06:18,600 --> 00:06:19,380
An attack.

77
00:06:23,200 --> 00:06:29,380
And you will see now that the test job stage has succeeded and that the fix that we have found online

78
00:06:29,380 --> 00:06:35,710
seems to be working and as I have said with test changed a string here, make sure that it fails, make

79
00:06:35,710 --> 00:06:41,650
sure that everything works properly before just leaving it in production and relying on things where

80
00:06:41,650 --> 00:06:42,280
you're not sure.

81
00:06:43,910 --> 00:06:50,990
So let's review again what we have learned in this lecture, we have added a new job and because two

82
00:06:50,990 --> 00:06:56,100
jobs now are in the stage test, this test are being executed in parallel.

83
00:06:56,780 --> 00:07:03,830
Now, in this first one test artifact, we have used this Docker image Alpine, which is a very, very

84
00:07:03,830 --> 00:07:05,390
small, minimalistic image.

85
00:07:05,750 --> 00:07:09,790
But it's just enough for us to be able to run this script command.

86
00:07:10,010 --> 00:07:12,760
And as you have seen, it executes very, very fast.

87
00:07:12,860 --> 00:07:17,800
It's like 20 seconds to download the image, stouter image and run the script that we have.

88
00:07:18,560 --> 00:07:27,140
And in this second job that is running in parallel, we are using the node image we have then the script

89
00:07:27,140 --> 00:07:33,380
we have to install NPM in order to use Gatsby and we're using Gatsby to start the server.

90
00:07:33,830 --> 00:07:41,120
We are using this and operator, which makes this command run in the background and it's releasing the

91
00:07:41,330 --> 00:07:46,070
terminal so that the next commands can be executed and we have to sleep.

92
00:07:46,070 --> 00:07:48,920
We are waiting a few seconds, give the server a chance to start.

93
00:07:49,580 --> 00:07:56,720
And after that, with Kerl and Whicker, we are calling this address and then waiting for the entire

94
00:07:57,200 --> 00:08:03,050
response to be written, the tech tech command that we have used as a solution to the error that we

95
00:08:03,050 --> 00:08:05,270
were getting and then we'd grippe.

96
00:08:05,300 --> 00:08:06,620
We are searching for this string.