summaryrefslogtreecommitdiff
path: root/media/simulation.vtt
blob: 0daee666aa3eae0d443d8136a73b80597b1f4a0d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
WEBVTT

00:00:00.000 --> 00:00:05.843
Zuul can be used to ensure that every commit
merged into a project has passed tests

00:00:05.844 --> 00:00:09.442
and the project continues to work
with its dependencies.

00:00:09.443 --> 00:00:14.402
When a change or pull request is approved
Zuul adds it to the gate pipeline.

00:00:14.403 --> 00:00:18.242
This pipeline holds changes to be merged
into their respective projects

00:00:18.243 --> 00:00:20.882
in the order in which they are going to merge.

00:00:20.883 --> 00:00:23.282
This ordering can be determined explicitly

00:00:23.283 --> 00:00:25.843
if a user adds a "Depends-On" line
to the commit message.

00:00:25.844 --> 00:00:30.003
In that case, Zuul will make sure that the
dependency is enqueued first

00:00:30.004 --> 00:00:32.551
followed by the change that depends on it.

00:00:32.552 --> 00:00:36.657
Or as in this case the order might simply be
determined by the order

00:00:36.658 --> 00:00:39.616
in which changes are approved
by the project's developers.

00:00:39.617 --> 00:00:41.290
In the example shown here

00:00:41.291 --> 00:00:44.174
developers have approved
two changes to Nova,

00:00:44.177 --> 00:00:45.700
one change to Keystone,

00:00:45.701 --> 00:00:48.094
followed by one more change to Nova.

00:00:48.097 --> 00:00:50.896
As soon as a change is enqueued
into the gate pipeline

00:00:50.897 --> 00:00:53.376
Zuul starts running jobs for that change.

00:00:53.377 --> 00:00:57.216
Each item in the pipeline represents
a future state of its project

00:00:57.217 --> 00:01:01.616
but also includes the future state
of all the projects ahead of it in the queue.

00:01:01.617 --> 00:01:05.136
So in this case, the tests which are running
on the second Nova change

00:01:05.137 --> 00:01:08.816
include the commit for that change
as well as the first.

00:01:08.817 --> 00:01:12.977
Nova and Keystone are tested together
in the integration test job

00:01:12.978 --> 00:01:15.596
so when that job runs on change #3

00:01:15.597 --> 00:01:17.836
it is testing not only the Keystone change

00:01:17.837 --> 00:01:20.156
but both Nova changes as well.

00:01:20.157 --> 00:01:24.071
Inside that test job,
it is as if all the changes ahead of it

00:01:24.072 --> 00:01:25.991
in the queue have already merged.

00:01:25.992 --> 00:01:30.631
In this way, Zuul tests the changes as they
would be merged into the git repository

00:01:30.632 --> 00:01:32.711
not simply as they were written.

00:01:32.712 --> 00:01:35.351
Zuul runs all of these tests in parallel

00:01:35.352 --> 00:01:36.951
but as soon as a job fails,

00:01:36.952 --> 00:01:39.491
the future that Zuul predicted
is no longer valid --

00:01:39.492 --> 00:01:42.051
we know that change is not going to merge.

00:01:42.052 --> 00:01:45.651
All of the tests for changes behind it
in the queue are outdated

00:01:45.652 --> 00:01:48.611
so Zuul cancels any running jobs
for those changes.

00:01:48.612 --> 00:01:52.051
Here we can see that not only has
change #4 failed

00:01:52.052 --> 00:01:54.451
but change #3 has as well.

00:01:54.452 --> 00:01:57.651
Because #3 failed and is no longer
eligible to merge

00:01:57.652 --> 00:02:01.171
Zuul has invalidated the earlier
test results for #4

00:02:01.172 --> 00:02:06.371
and has re-started jobs for #4 with only
changes #1 and #2 included this time.

00:02:06.372 --> 00:02:11.151
Change #3 stays in the queue in case
one of the changes ahead of it fails

00:02:11.152 --> 00:02:14.512
but unless that happens it will not be merged.

00:02:14.513 --> 00:02:17.472
As changes #1 and #2 complete their tests

00:02:17.473 --> 00:02:20.592
each of them is merged into
the Nova repository.

00:02:20.593 --> 00:02:21.794
Once that is complete

00:02:21.795 --> 00:02:26.914
it is safe to report the Keystone change #3
as having failed its tests

00:02:26.915 --> 00:02:30.274
Finally, the tests for Nova
change #4 are passing now

00:02:30.275 --> 00:02:33.714
confirming that the earlier problem
was due to the Keystone change

00:02:33.715 --> 00:02:37.053
Zuul merges the final Nova
change into the repository

00:02:37.054 --> 00:02:39.766
once all tests are complete.