Browse Source

Add simulation video

Change-Id: I5dc8bfca61d536a825be11f7721ddb60e74c827b
changes/01/562001/3
James E. Blair 1 year ago
parent
commit
0a213fc51a
5 changed files with 181 additions and 1 deletions
  1. 0
    1
      media/README.txt
  2. BIN
      media/simulation-poster.png
  3. BIN
      media/simulation.mp4
  4. 181
    0
      media/simulation.vtt
  5. BIN
      media/simulation.webm

+ 0
- 1
media/README.txt View File

@@ -1 +0,0 @@
1
-Placeholder.

BIN
media/simulation-poster.png View File


BIN
media/simulation.mp4 View File


+ 181
- 0
media/simulation.vtt View File

@@ -0,0 +1,181 @@
1
+WEBVTT
2
+
3
+00:00:00.000 --> 00:00:05.843
4
+Zuul can be used to ensure that every commit
5
+merged into a project has passed tests
6
+
7
+00:00:05.844 --> 00:00:09.442
8
+and the project continues to work
9
+with its dependencies.
10
+
11
+00:00:09.443 --> 00:00:14.402
12
+When a change or pull request is approved
13
+Zuul adds it to the gate pipeline.
14
+
15
+00:00:14.403 --> 00:00:18.242
16
+This pipeline holds changes to be merged
17
+into their respective projects
18
+
19
+00:00:18.243 --> 00:00:20.882
20
+in the order in which they are going to merge.
21
+
22
+00:00:20.883 --> 00:00:23.282
23
+This ordering can be determined explicitly
24
+
25
+00:00:23.283 --> 00:00:25.843
26
+if a user adds a "Depends-On" line
27
+to the commit message.
28
+
29
+00:00:25.844 --> 00:00:30.003
30
+In that case, Zuul will make sure that the
31
+dependency is enqueued first
32
+
33
+00:00:30.004 --> 00:00:32.551
34
+followed by the change that depends on it.
35
+
36
+00:00:32.552 --> 00:00:36.657
37
+Or as in this case the order might simply be
38
+determined by the order
39
+
40
+00:00:36.658 --> 00:00:39.616
41
+in which changes are approved
42
+by the project's developers.
43
+
44
+00:00:39.617 --> 00:00:41.290
45
+In the example shown here
46
+
47
+00:00:41.291 --> 00:00:44.174
48
+developers have approved
49
+two changes to Nova,
50
+
51
+00:00:44.177 --> 00:00:45.700
52
+one change to Keystone,
53
+
54
+00:00:45.701 --> 00:00:48.094
55
+followed by one more change to Nova.
56
+
57
+00:00:48.097 --> 00:00:50.896
58
+As soon as a change is enqueued
59
+into the gate pipeline
60
+
61
+00:00:50.897 --> 00:00:53.376
62
+Zuul starts running jobs for that change.
63
+
64
+00:00:53.377 --> 00:00:57.216
65
+Each item in the pipeline represents
66
+a future state of its project
67
+
68
+00:00:57.217 --> 00:01:01.616
69
+but also includes the future state
70
+of all the projects ahead of it in the queue.
71
+
72
+00:01:01.617 --> 00:01:05.136
73
+So in this case, the tests which are running
74
+on the second Nova change
75
+
76
+00:01:05.137 --> 00:01:08.816
77
+include the commit for that change
78
+as well as the first.
79
+
80
+00:01:08.817 --> 00:01:12.977
81
+Nova and Keystone are tested together
82
+in the integration test job
83
+
84
+00:01:12.978 --> 00:01:15.596
85
+so when that job runs on change #3
86
+
87
+00:01:15.597 --> 00:01:17.836
88
+it is testing not only the Keystone change
89
+
90
+00:01:17.837 --> 00:01:20.156
91
+but both Nova changes as well.
92
+
93
+00:01:20.157 --> 00:01:24.071
94
+Inside that test job,
95
+it is as if all the changes ahead of it
96
+
97
+00:01:24.072 --> 00:01:25.991
98
+in the queue have already merged.
99
+
100
+00:01:25.992 --> 00:01:30.631
101
+In this way, Zuul tests the changes as they
102
+would be merged into the git repository
103
+
104
+00:01:30.632 --> 00:01:32.711
105
+not simply as they were written.
106
+
107
+00:01:32.712 --> 00:01:35.351
108
+Zuul runs all of these tests in parallel
109
+
110
+00:01:35.352 --> 00:01:36.951
111
+but as soon as a job fails,
112
+
113
+00:01:36.952 --> 00:01:39.491
114
+the future that Zuul predicted
115
+is no longer valid --
116
+
117
+00:01:39.492 --> 00:01:42.051
118
+we know that change is not going to merge.
119
+
120
+00:01:42.052 --> 00:01:45.651
121
+All of the tests for changes behind it
122
+in the queue are outdated
123
+
124
+00:01:45.652 --> 00:01:48.611
125
+so Zuul cancels any running jobs
126
+for those changes.
127
+
128
+00:01:48.612 --> 00:01:52.051
129
+Here we can see that not only has
130
+change #4 failed
131
+
132
+00:01:52.052 --> 00:01:54.451
133
+but change #3 has as well.
134
+
135
+00:01:54.452 --> 00:01:57.651
136
+Because #3 failed and is no longer
137
+eligible to merge
138
+
139
+00:01:57.652 --> 00:02:01.171
140
+Zuul has invalidated the earlier
141
+test results for #4
142
+
143
+00:02:01.172 --> 00:02:06.371
144
+and has re-started jobs for #4 with only
145
+changes #1 and #2 included this time.
146
+
147
+00:02:06.372 --> 00:02:11.151
148
+Change #3 stays in the queue in case
149
+one of the changes ahead of it fails
150
+
151
+00:02:11.152 --> 00:02:14.512
152
+but unless that happens it will not be merged.
153
+
154
+00:02:14.513 --> 00:02:17.472
155
+As changes #1 and #2 complete their tests
156
+
157
+00:02:17.473 --> 00:02:20.592
158
+each of them is merged into
159
+the Nova repository.
160
+
161
+00:02:20.593 --> 00:02:21.794
162
+Once that is complete
163
+
164
+00:02:21.795 --> 00:02:26.914
165
+it is safe to report the Keystone change #3
166
+as having failed its tests
167
+
168
+00:02:26.915 --> 00:02:30.274
169
+Finally, the tests for Nova
170
+change #4 are passing now
171
+
172
+00:02:30.275 --> 00:02:33.714
173
+confirming that the earlier problem
174
+was due to the Keystone change
175
+
176
+00:02:33.715 --> 00:02:37.053
177
+Zuul merges the final Nova
178
+change into the repository
179
+
180
+00:02:37.054 --> 00:02:39.766
181
+once all tests are complete.

BIN
media/simulation.webm View File


Loading…
Cancel
Save