Large media files for the Zuul website
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

simulation.vtt 4.1KB

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