1
00:00:01,040 --> 00:00:02,060
[Autogenerated] So next we're going to

2
00:00:02,060 --> 00:00:04,690
utilize get bisect to detect bad commits

3
00:00:04,690 --> 00:00:06,780
within our repositories. So over the

4
00:00:06,780 --> 00:00:09,240
course of this demo, we will first utilize

5
00:00:09,240 --> 00:00:11,820
get by ___ manual mode to find wind. Bad

6
00:00:11,820 --> 00:00:13,800
code was injected, but then will be

7
00:00:13,800 --> 00:00:15,740
integrating. Get bisect with test to

8
00:00:15,740 --> 00:00:18,760
automatically find a bad codecommit. So

9
00:00:18,760 --> 00:00:20,460
the first thing we need to do is clone the

10
00:00:20,460 --> 00:00:22,230
example Java script project that we used

11
00:00:22,230 --> 00:00:24,740
within a previous module. Next, we're

12
00:00:24,740 --> 00:00:27,970
going to change into that directory from

13
00:00:27,970 --> 00:00:30,350
here. The next step is we need to run in P

14
00:00:30,350 --> 00:00:31,920
m. Installed to pull down the project

15
00:00:31,920 --> 00:00:35,920
Dependencies. Next, we'll check out a

16
00:00:35,920 --> 00:00:38,400
branch, I'll call, get fetch and then

17
00:00:38,400 --> 00:00:41,510
we'll check out the bisect branch from

18
00:00:41,510 --> 00:00:43,880
here. We're going to run our index dot Js

19
00:00:43,880 --> 00:00:46,120
file now just a za reminder. This file

20
00:00:46,120 --> 00:00:48,570
allows us to pass in a number, and that

21
00:00:48,570 --> 00:00:50,840
number is the max and we'll find prime

22
00:00:50,840 --> 00:00:53,410
numbers up to the max value. Now, in this

23
00:00:53,410 --> 00:00:57,240
case, I'm going to run up to 100 and when

24
00:00:57,240 --> 00:00:59,340
we do, we'll see that it found 15 primes

25
00:00:59,340 --> 00:01:02,050
between zero and 100. But that actually is

26
00:01:02,050 --> 00:01:04,630
incorrect. We should be finding 25 primes

27
00:01:04,630 --> 00:01:06,420
between zero and 100. So we know that

28
00:01:06,420 --> 00:01:08,950
there is a problem in our code and we can

29
00:01:08,950 --> 00:01:11,030
verify that by actually running in P M

30
00:01:11,030 --> 00:01:14,750
test and we can see here that we have four

31
00:01:14,750 --> 00:01:18,030
different failures. We have no test

32
00:01:18,030 --> 00:01:21,230
passing and all failing. Next, we need to

33
00:01:21,230 --> 00:01:22,710
look at the commits that have been made

34
00:01:22,710 --> 00:01:26,260
into this branch. So we have one commit

35
00:01:26,260 --> 00:01:28,160
here, which is breaking the fine primes

36
00:01:28,160 --> 00:01:30,420
dot Js logic. Now, this is the committee

37
00:01:30,420 --> 00:01:32,270
ultimately that we won't get bisect to

38
00:01:32,270 --> 00:01:35,470
find for us. We're going to specify the

39
00:01:35,470 --> 00:01:37,480
commit for updating our getting nor file

40
00:01:37,480 --> 00:01:39,260
as our good commit. Because we know it was

41
00:01:39,260 --> 00:01:41,690
working at this point and we'll utilize

42
00:01:41,690 --> 00:01:44,130
the add more tests, commit to be the

43
00:01:44,130 --> 00:01:45,990
commit where this is our bad commit

44
00:01:45,990 --> 00:01:47,630
because we know that this is a point where

45
00:01:47,630 --> 00:01:50,280
it was no longer working. So I'm gonna go

46
00:01:50,280 --> 00:01:52,230
ahead and exit out of here and we'll go

47
00:01:52,230 --> 00:01:55,240
ahead and inter get Bisek mode now from

48
00:01:55,240 --> 00:01:57,870
here, our next step is to specify are good

49
00:01:57,870 --> 00:02:00,840
commit then we need to specify are bad

50
00:02:00,840 --> 00:02:03,660
commit now we've currently entered get

51
00:02:03,660 --> 00:02:06,010
bisect mode and get bisect is waiting for

52
00:02:06,010 --> 00:02:07,840
us to determine whether or not the current

53
00:02:07,840 --> 00:02:10,190
commit that we're on is good or bad. We

54
00:02:10,190 --> 00:02:11,830
contest this by simply running our index

55
00:02:11,830 --> 00:02:14,610
dot Js file. In this case, we can see that

56
00:02:14,610 --> 00:02:18,100
it is returning 15 primes instead of 25.

57
00:02:18,100 --> 00:02:21,920
So we know that we still are bad now. Next

58
00:02:21,920 --> 00:02:24,000
were actually on the committee where it is

59
00:02:24,000 --> 00:02:25,920
breaking. And so in this case, we're going

60
00:02:25,920 --> 00:02:29,360
to run our index dot Js file again and we

61
00:02:29,360 --> 00:02:30,830
can see that it is still returning the

62
00:02:30,830 --> 00:02:33,010
incorrect value. So we'll specify this

63
00:02:33,010 --> 00:02:36,740
commit is bad. And it lets us know then

64
00:02:36,740 --> 00:02:39,360
that this is the first bad commit. It has

65
00:02:39,360 --> 00:02:41,100
done the analysis and it is determined

66
00:02:41,100 --> 00:02:43,330
that this is the point where the bad logic

67
00:02:43,330 --> 00:02:46,840
was injected. We can now run get show.

68
00:02:46,840 --> 00:02:48,910
From here, you can see that there was a

69
00:02:48,910 --> 00:02:50,690
single line that was passed in. In this

70
00:02:50,690 --> 00:02:53,390
case, it is cutting the max value in half

71
00:02:53,390 --> 00:02:54,970
from the max value that is being passed

72
00:02:54,970 --> 00:02:56,700
into the function. So we know that this is

73
00:02:56,700 --> 00:02:59,560
the logic that caused it to break. So now

74
00:02:59,560 --> 00:03:02,280
I'm gonna exit out of get show now. Once

75
00:03:02,280 --> 00:03:04,840
we're done to exit out of get bisect. We

76
00:03:04,840 --> 00:03:09,310
simply need to run, get bisect. Reset. Now

77
00:03:09,310 --> 00:03:12,340
we have exited out of Get Bisek mode. Now

78
00:03:12,340 --> 00:03:14,270
the next step is we're going to inter get

79
00:03:14,270 --> 00:03:17,460
bisect mode again and in this case,

80
00:03:17,460 --> 00:03:19,380
instead of using the manual process, we're

81
00:03:19,380 --> 00:03:21,750
going to use the automated process. But

82
00:03:21,750 --> 00:03:23,400
our first step is still the same. We need

83
00:03:23,400 --> 00:03:26,560
to specify are good commit and we need to

84
00:03:26,560 --> 00:03:29,980
specify are bad commit now in this case,

85
00:03:29,980 --> 00:03:31,520
we're going to use get bisect and we're

86
00:03:31,520 --> 00:03:33,680
going to tell it to run our test suite and

87
00:03:33,680 --> 00:03:35,510
it can run our test suite by running in p

88
00:03:35,510 --> 00:03:39,480
m test. It now went through the process

89
00:03:39,480 --> 00:03:41,690
and it landed at the same conclusion that

90
00:03:41,690 --> 00:03:43,890
the breaking the fine primes dot Js logic

91
00:03:43,890 --> 00:03:46,380
commit was indeed the one where the bad

92
00:03:46,380 --> 00:03:48,890
code was injected. Now, some of you might

93
00:03:48,890 --> 00:03:50,860
be worried if you don't have tests at the

94
00:03:50,860 --> 00:03:52,830
point when you think that the bad code was

95
00:03:52,830 --> 00:03:54,990
injected. However, if you include tests

96
00:03:54,990 --> 00:03:56,720
that are not a part of your repositories,

97
00:03:56,720 --> 00:03:58,480
they will not be wiped out when get by

98
00:03:58,480 --> 00:04:01,310
___, which is between different commits

99
00:04:01,310 --> 00:04:03,150
and so in that case, you can still use the

100
00:04:03,150 --> 00:04:05,250
automated process as long as you keep

101
00:04:05,250 --> 00:04:07,010
those tests that you're using to validate

102
00:04:07,010 --> 00:04:12,000
whether or not a commit is good or bad out of the repositories for the time being.

