The Gatekeeper, or a project gating system
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.

.zuul.yaml 9.6KB

Use yarn and webpack to manage zuul-web javascript yarn drives package and dependency management. webpack handles bundling, minification and transpiling down to browser-acceptable javascript but allows for more modern javascript like import statements. There are some really neat things in the webpack dev server. CSS changes, for instance, get applied immediately without a refresh. Other things, like the jquery plugin do need a refresh, but it's handled just on a file changing. As a followup, we can also consider turning the majority of the status page into a webpack library that other people can depend on as a mechanism for direct use. Things like that haven't been touched because allowing folks to poke at the existing known status page without too many changes using the tools seems like a good way for people to learn/understand the stack. Move things so that the built content gets put into zuul/web/static so that the built-in static serving from zuul-web will/can serve the files. Update MANIFEST.in so that if npm run build:dist is run before the python setup.py sdist, the built html/javascript content will be included in the source tarball. Add a pbr hook so that if yarn is installed, javascript content will be built before the tarball. Add a zuul job with a success url that contains a source_url pointing to the live v3 data. This adds a framework for verifying that we can serve the web app urls and their dependencies for all of the various ways we want to support folks hosting zuul-web. It includes a very simple reverse proxy server for approximating what we do in openstack to "white label" the Zuul service -- that is, hide the multitenancy aspect and present the single tenant at the site root. We can run similar tests without the proxy to ensure the default, multi-tenant view works as well. Add babel transpiling enabling use of ES6 features ECMAScript6 has a bunch of nice things, like block scoped variables, const, template strings and classes. Babel is a javascript transpiler which webpack can use to allow us to write using modern javascript but the resulting code to still work on older browsers. Use the babel-plugin-angularjs-annotate so that angular's dependency injection doesn't get borked by babel's transpiling things (which causes variables to otherwise be renamed in a way that causes angular to not find them) While we're at it, replace our use of var with let (let is the new block-scoped version of var) and toss in some use of const and template strings for good measure. Add StandardJS eslint config for linting JavaScript Standard Style is a code style similar to pep8/flake8. It's being added here not because of the pep8 part, but because the pyflakes equivalent can catch real errors. This uses the babel-eslint parser since we're using Babel to transpile already. This auto-formats the existing code with: npm run format Rather than using StandardJS directly through the 'standard' package, use the standardjs eslint plugin so that we can ignore the camelCase rule (and any other rule that might emerge in the future) Many of under_score/camelCase were fixed in a previous version of the patch. Since the prevailing zuul style is camelCase methods anyway, those fixes were left. That warning has now been disabled. Other things, such as == vs. === and ensuring template strings are in backticks are fixed. Ignore indentation errors for now - we'll fix them at the end of this stack and then remove the exclusion. Add a 'format' npm run target that will run the eslint command with --fix for ease of fixing reported issues. Add a 'lint' npm run target and a 'lint' environment that runs with linting turned to errors. The next patch makes the lint environment more broadly useful. When we run lint, also run the BundleAnalyzerPlugin and set the success-url to the report. Add an angular controller for status and stream page Wrap the status and stream page construction with an angular controller so that all the javascripts can be bundled in a single file. Building the files locally is wonderful and all, but what we really want is to make a tarball that has the built code so that it can be deployed. Put it in the root source dir so that it can be used with the zuul fetch-javascript-tarball role. Also, replace the custom npm job with the new build-javascript-content job which naturally grabs the content we want. Make a 'main.js' file that imports the other three so that we just have a single bundle. Then, add a 'vendor' entry in the common webpack file and use the CommonsChunkPlugin to extract dependencies into their own bundle. A second CommonsChunkPlugin entry pulls out a little bit of metadata that would otherwise cause the main and vendor chunks to change even with no source change. Then add chunkhash into the filename. This way the files themselves can be aggressively cached. This all follows recommendations from https://webpack.js.org/guides/caching/ https://webpack.js.org/guides/code-splitting/ and https://webpack.js.org/guides/output-management/ Change-Id: I2e1230783fe57f1bc3b7818460463df1e659936b Co-Authored-By: Tristan Cacqueray <tdecacqu@redhat.com> Co-Authored-By: James E. Blair <jeblair@redhat.com>
2 years ago
Use yarn and webpack to manage zuul-web javascript yarn drives package and dependency management. webpack handles bundling, minification and transpiling down to browser-acceptable javascript but allows for more modern javascript like import statements. There are some really neat things in the webpack dev server. CSS changes, for instance, get applied immediately without a refresh. Other things, like the jquery plugin do need a refresh, but it's handled just on a file changing. As a followup, we can also consider turning the majority of the status page into a webpack library that other people can depend on as a mechanism for direct use. Things like that haven't been touched because allowing folks to poke at the existing known status page without too many changes using the tools seems like a good way for people to learn/understand the stack. Move things so that the built content gets put into zuul/web/static so that the built-in static serving from zuul-web will/can serve the files. Update MANIFEST.in so that if npm run build:dist is run before the python setup.py sdist, the built html/javascript content will be included in the source tarball. Add a pbr hook so that if yarn is installed, javascript content will be built before the tarball. Add a zuul job with a success url that contains a source_url pointing to the live v3 data. This adds a framework for verifying that we can serve the web app urls and their dependencies for all of the various ways we want to support folks hosting zuul-web. It includes a very simple reverse proxy server for approximating what we do in openstack to "white label" the Zuul service -- that is, hide the multitenancy aspect and present the single tenant at the site root. We can run similar tests without the proxy to ensure the default, multi-tenant view works as well. Add babel transpiling enabling use of ES6 features ECMAScript6 has a bunch of nice things, like block scoped variables, const, template strings and classes. Babel is a javascript transpiler which webpack can use to allow us to write using modern javascript but the resulting code to still work on older browsers. Use the babel-plugin-angularjs-annotate so that angular's dependency injection doesn't get borked by babel's transpiling things (which causes variables to otherwise be renamed in a way that causes angular to not find them) While we're at it, replace our use of var with let (let is the new block-scoped version of var) and toss in some use of const and template strings for good measure. Add StandardJS eslint config for linting JavaScript Standard Style is a code style similar to pep8/flake8. It's being added here not because of the pep8 part, but because the pyflakes equivalent can catch real errors. This uses the babel-eslint parser since we're using Babel to transpile already. This auto-formats the existing code with: npm run format Rather than using StandardJS directly through the 'standard' package, use the standardjs eslint plugin so that we can ignore the camelCase rule (and any other rule that might emerge in the future) Many of under_score/camelCase were fixed in a previous version of the patch. Since the prevailing zuul style is camelCase methods anyway, those fixes were left. That warning has now been disabled. Other things, such as == vs. === and ensuring template strings are in backticks are fixed. Ignore indentation errors for now - we'll fix them at the end of this stack and then remove the exclusion. Add a 'format' npm run target that will run the eslint command with --fix for ease of fixing reported issues. Add a 'lint' npm run target and a 'lint' environment that runs with linting turned to errors. The next patch makes the lint environment more broadly useful. When we run lint, also run the BundleAnalyzerPlugin and set the success-url to the report. Add an angular controller for status and stream page Wrap the status and stream page construction with an angular controller so that all the javascripts can be bundled in a single file. Building the files locally is wonderful and all, but what we really want is to make a tarball that has the built code so that it can be deployed. Put it in the root source dir so that it can be used with the zuul fetch-javascript-tarball role. Also, replace the custom npm job with the new build-javascript-content job which naturally grabs the content we want. Make a 'main.js' file that imports the other three so that we just have a single bundle. Then, add a 'vendor' entry in the common webpack file and use the CommonsChunkPlugin to extract dependencies into their own bundle. A second CommonsChunkPlugin entry pulls out a little bit of metadata that would otherwise cause the main and vendor chunks to change even with no source change. Then add chunkhash into the filename. This way the files themselves can be aggressively cached. This all follows recommendations from https://webpack.js.org/guides/caching/ https://webpack.js.org/guides/code-splitting/ and https://webpack.js.org/guides/output-management/ Change-Id: I2e1230783fe57f1bc3b7818460463df1e659936b Co-Authored-By: Tristan Cacqueray <tdecacqu@redhat.com> Co-Authored-By: James E. Blair <jeblair@redhat.com>
2 years ago
Use yarn and webpack to manage zuul-web javascript yarn drives package and dependency management. webpack handles bundling, minification and transpiling down to browser-acceptable javascript but allows for more modern javascript like import statements. There are some really neat things in the webpack dev server. CSS changes, for instance, get applied immediately without a refresh. Other things, like the jquery plugin do need a refresh, but it's handled just on a file changing. As a followup, we can also consider turning the majority of the status page into a webpack library that other people can depend on as a mechanism for direct use. Things like that haven't been touched because allowing folks to poke at the existing known status page without too many changes using the tools seems like a good way for people to learn/understand the stack. Move things so that the built content gets put into zuul/web/static so that the built-in static serving from zuul-web will/can serve the files. Update MANIFEST.in so that if npm run build:dist is run before the python setup.py sdist, the built html/javascript content will be included in the source tarball. Add a pbr hook so that if yarn is installed, javascript content will be built before the tarball. Add a zuul job with a success url that contains a source_url pointing to the live v3 data. This adds a framework for verifying that we can serve the web app urls and their dependencies for all of the various ways we want to support folks hosting zuul-web. It includes a very simple reverse proxy server for approximating what we do in openstack to "white label" the Zuul service -- that is, hide the multitenancy aspect and present the single tenant at the site root. We can run similar tests without the proxy to ensure the default, multi-tenant view works as well. Add babel transpiling enabling use of ES6 features ECMAScript6 has a bunch of nice things, like block scoped variables, const, template strings and classes. Babel is a javascript transpiler which webpack can use to allow us to write using modern javascript but the resulting code to still work on older browsers. Use the babel-plugin-angularjs-annotate so that angular's dependency injection doesn't get borked by babel's transpiling things (which causes variables to otherwise be renamed in a way that causes angular to not find them) While we're at it, replace our use of var with let (let is the new block-scoped version of var) and toss in some use of const and template strings for good measure. Add StandardJS eslint config for linting JavaScript Standard Style is a code style similar to pep8/flake8. It's being added here not because of the pep8 part, but because the pyflakes equivalent can catch real errors. This uses the babel-eslint parser since we're using Babel to transpile already. This auto-formats the existing code with: npm run format Rather than using StandardJS directly through the 'standard' package, use the standardjs eslint plugin so that we can ignore the camelCase rule (and any other rule that might emerge in the future) Many of under_score/camelCase were fixed in a previous version of the patch. Since the prevailing zuul style is camelCase methods anyway, those fixes were left. That warning has now been disabled. Other things, such as == vs. === and ensuring template strings are in backticks are fixed. Ignore indentation errors for now - we'll fix them at the end of this stack and then remove the exclusion. Add a 'format' npm run target that will run the eslint command with --fix for ease of fixing reported issues. Add a 'lint' npm run target and a 'lint' environment that runs with linting turned to errors. The next patch makes the lint environment more broadly useful. When we run lint, also run the BundleAnalyzerPlugin and set the success-url to the report. Add an angular controller for status and stream page Wrap the status and stream page construction with an angular controller so that all the javascripts can be bundled in a single file. Building the files locally is wonderful and all, but what we really want is to make a tarball that has the built code so that it can be deployed. Put it in the root source dir so that it can be used with the zuul fetch-javascript-tarball role. Also, replace the custom npm job with the new build-javascript-content job which naturally grabs the content we want. Make a 'main.js' file that imports the other three so that we just have a single bundle. Then, add a 'vendor' entry in the common webpack file and use the CommonsChunkPlugin to extract dependencies into their own bundle. A second CommonsChunkPlugin entry pulls out a little bit of metadata that would otherwise cause the main and vendor chunks to change even with no source change. Then add chunkhash into the filename. This way the files themselves can be aggressively cached. This all follows recommendations from https://webpack.js.org/guides/caching/ https://webpack.js.org/guides/code-splitting/ and https://webpack.js.org/guides/output-management/ Change-Id: I2e1230783fe57f1bc3b7818460463df1e659936b Co-Authored-By: Tristan Cacqueray <tdecacqu@redhat.com> Co-Authored-By: James E. Blair <jeblair@redhat.com>
2 years ago
Use yarn and webpack to manage zuul-web javascript yarn drives package and dependency management. webpack handles bundling, minification and transpiling down to browser-acceptable javascript but allows for more modern javascript like import statements. There are some really neat things in the webpack dev server. CSS changes, for instance, get applied immediately without a refresh. Other things, like the jquery plugin do need a refresh, but it's handled just on a file changing. As a followup, we can also consider turning the majority of the status page into a webpack library that other people can depend on as a mechanism for direct use. Things like that haven't been touched because allowing folks to poke at the existing known status page without too many changes using the tools seems like a good way for people to learn/understand the stack. Move things so that the built content gets put into zuul/web/static so that the built-in static serving from zuul-web will/can serve the files. Update MANIFEST.in so that if npm run build:dist is run before the python setup.py sdist, the built html/javascript content will be included in the source tarball. Add a pbr hook so that if yarn is installed, javascript content will be built before the tarball. Add a zuul job with a success url that contains a source_url pointing to the live v3 data. This adds a framework for verifying that we can serve the web app urls and their dependencies for all of the various ways we want to support folks hosting zuul-web. It includes a very simple reverse proxy server for approximating what we do in openstack to "white label" the Zuul service -- that is, hide the multitenancy aspect and present the single tenant at the site root. We can run similar tests without the proxy to ensure the default, multi-tenant view works as well. Add babel transpiling enabling use of ES6 features ECMAScript6 has a bunch of nice things, like block scoped variables, const, template strings and classes. Babel is a javascript transpiler which webpack can use to allow us to write using modern javascript but the resulting code to still work on older browsers. Use the babel-plugin-angularjs-annotate so that angular's dependency injection doesn't get borked by babel's transpiling things (which causes variables to otherwise be renamed in a way that causes angular to not find them) While we're at it, replace our use of var with let (let is the new block-scoped version of var) and toss in some use of const and template strings for good measure. Add StandardJS eslint config for linting JavaScript Standard Style is a code style similar to pep8/flake8. It's being added here not because of the pep8 part, but because the pyflakes equivalent can catch real errors. This uses the babel-eslint parser since we're using Babel to transpile already. This auto-formats the existing code with: npm run format Rather than using StandardJS directly through the 'standard' package, use the standardjs eslint plugin so that we can ignore the camelCase rule (and any other rule that might emerge in the future) Many of under_score/camelCase were fixed in a previous version of the patch. Since the prevailing zuul style is camelCase methods anyway, those fixes were left. That warning has now been disabled. Other things, such as == vs. === and ensuring template strings are in backticks are fixed. Ignore indentation errors for now - we'll fix them at the end of this stack and then remove the exclusion. Add a 'format' npm run target that will run the eslint command with --fix for ease of fixing reported issues. Add a 'lint' npm run target and a 'lint' environment that runs with linting turned to errors. The next patch makes the lint environment more broadly useful. When we run lint, also run the BundleAnalyzerPlugin and set the success-url to the report. Add an angular controller for status and stream page Wrap the status and stream page construction with an angular controller so that all the javascripts can be bundled in a single file. Building the files locally is wonderful and all, but what we really want is to make a tarball that has the built code so that it can be deployed. Put it in the root source dir so that it can be used with the zuul fetch-javascript-tarball role. Also, replace the custom npm job with the new build-javascript-content job which naturally grabs the content we want. Make a 'main.js' file that imports the other three so that we just have a single bundle. Then, add a 'vendor' entry in the common webpack file and use the CommonsChunkPlugin to extract dependencies into their own bundle. A second CommonsChunkPlugin entry pulls out a little bit of metadata that would otherwise cause the main and vendor chunks to change even with no source change. Then add chunkhash into the filename. This way the files themselves can be aggressively cached. This all follows recommendations from https://webpack.js.org/guides/caching/ https://webpack.js.org/guides/code-splitting/ and https://webpack.js.org/guides/output-management/ Change-Id: I2e1230783fe57f1bc3b7818460463df1e659936b Co-Authored-By: Tristan Cacqueray <tdecacqu@redhat.com> Co-Authored-By: James E. Blair <jeblair@redhat.com>
2 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315
  1. - nodeset:
  2. name: zuul-functional-temp-master
  3. nodes:
  4. - name: controller
  5. label: ubuntu-xenial
  6. - name: node1
  7. label: ubuntu-xenial
  8. - name: node2
  9. label: ubuntu-xenial
  10. groups:
  11. - name: node
  12. nodes:
  13. - node1
  14. - node2
  15. - job:
  16. name: zuul-stream-functional
  17. parent: multinode
  18. nodeset: zuul-functional-temp-master
  19. pre-run: playbooks/zuul-stream/pre.yaml
  20. run: playbooks/zuul-stream/functional.yaml
  21. post-run:
  22. - playbooks/zuul-stream/post.yaml
  23. - playbooks/zuul-stream/post-ara.yaml
  24. files:
  25. - zuul/ansible/.*
  26. - zuul/lib/ansible*
  27. - playbooks/zuul-stream/.*
  28. - job:
  29. name: zuul-stream-functional-2.7
  30. parent: zuul-stream-functional
  31. # Force executor to use same Ansible version as "controller" node so
  32. # that the inventory.yaml file will be correct for that version.
  33. ansible-version: 2.7
  34. vars:
  35. zuul_ansible_version: 2.7
  36. - job:
  37. name: zuul-stream-functional-2.8
  38. parent: zuul-stream-functional
  39. # Force executor to use same Ansible version as "controller" node so
  40. # that the inventory.yaml file will be correct for that version.
  41. ansible-version: 2.8
  42. vars:
  43. zuul_ansible_version: 2.8
  44. - job:
  45. name: zuul-stream-functional-2.9
  46. parent: zuul-stream-functional
  47. success-url: 'http://zuul.opendev.org/t/zuul/build/{build.uuid}'
  48. failure-url: 'http://zuul.opendev.org/t/zuul/build/{build.uuid}'
  49. vars:
  50. zuul_ansible_version: 2.9
  51. - job:
  52. name: zuul-tox-remote
  53. parent: tox
  54. vars:
  55. tox_envlist: remote
  56. tox_environment:
  57. ZUUL_SSH_KEY: /home/zuul/.ssh/id_rsa
  58. ZUUL_REMOTE_IPV4: "{{ nodepool.interface_ip }}"
  59. ZUUL_REMOTE_KEEP: "true"
  60. - job:
  61. name: zuul-build-dashboard
  62. parent: build-javascript-deployment
  63. success-url: 'npm/html/'
  64. files:
  65. - web/.*
  66. - playbooks/dashboard/.*
  67. vars:
  68. javascript_content_dir: "../zuul/web/static"
  69. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  70. create_tarball_directory: build
  71. run: playbooks/dashboard/run.yaml
  72. - job:
  73. name: zuul-build-dashboard-openstack-whitelabel
  74. parent: zuul-build-dashboard
  75. vars:
  76. zuul_api_url: https://zuul.openstack.org
  77. - job:
  78. name: zuul-build-dashboard-software-factory
  79. parent: zuul-build-dashboard
  80. vars:
  81. zuul_api_url: https://softwarefactory-project.io/zuul
  82. - job:
  83. name: zuul-build-dashboard-opendev
  84. parent: zuul-build-dashboard
  85. vars:
  86. zuul_api_url: https://zuul.opendev.org
  87. # This job is run on changes to both Zuul and Nodepool; any changes to
  88. # the other project will be picked up via image builds which appear in
  89. # the buildset registry. It includes zuul as a required project
  90. # because that is where the docker-compose file is located.
  91. - job:
  92. name: zuul-quick-start
  93. parent: opendev-buildset-registry-consumer
  94. description: Run the commands in the Zuul quick-start documentation.
  95. run: playbooks/quick-start/run.yaml
  96. post-run: playbooks/quick-start/post.yaml
  97. required-projects:
  98. - zuul/zuul
  99. # Image building jobs
  100. - secret:
  101. name: zuul-dockerhub
  102. data:
  103. username: zuulzuul
  104. password: !encrypted/pkcs1-oaep
  105. - DFlbrDM5eUMptMGIVMXV1g455xOJLi92UYF08Z2/JlIGu3t6v052o9FKlVyj1ZmpXs5+2
  106. JTa5jHkLTvTsYs9fCaNcQc2nmViCyWNlbOMzjB17uiZOaYFNs1sMqZcUZbGEz7Y8ds6Qq
  107. NBXI10jWFPTah4QxUuBvUbT3vmjnUToCzexl5ZGhKgijcnROWfUsnlCdugpgoNIcPsUki
  108. zty5FotDihnrC8n8vIomVK6EClY38ty97pLrADzFDd+Cos/OUlvi2xooUhzx8Bn020rJA
  109. lqEU5v8LGXp5QkHx0MSDx6JY6KppJ/4p/yM+4By6l+A20zdcimxmgiNc9rMWPwDj7xsao
  110. m7NAZWmWqOO0Xkhgt6WOfugwgt9X46sgs2+yDEfbnI5ok8uRbAB/4FWj/KdpyXwhcf+O2
  111. wEfhxLwDbAoGONQPjb4YcZmCXtmR7Qe5t+n2jyczWXvrbaBDUQP5a+YtVNN/xhmQ7D740
  112. POlxv7bLxJAixzqaQ3d8Rz9ZEv6zzRuhWph32UQtZ1JxSNww+EvmXm2eEi2Q2z6pT1Cx/
  113. j2OrFyA2GL/UJOVb15VHKF6bgHPHWJtpjPFhqdcvBhVute4BWB+KPcWH+y+apHN1enK3H
  114. tNJO9iqm34nKwSuj5ExmFw50LtwR5/9FyRuRPq/vBL+8y82v8FDmeYsBeobn5M=
  115. - job:
  116. name: zuul-build-image
  117. parent: opendev-build-docker-image
  118. description: Build Docker images.
  119. allowed-projects: zuul/zuul
  120. timeout: 2700 # 45 minutes
  121. requires:
  122. - python-builder-3.7-container-image
  123. - python-base-3.7-container-image
  124. provides: zuul-container-image
  125. vars: &zuul_image_vars
  126. docker_images:
  127. - context: .
  128. repository: zuul/zuul
  129. target: zuul
  130. - context: .
  131. repository: zuul/zuul-executor
  132. target: zuul-executor
  133. - context: .
  134. repository: zuul/zuul-fingergw
  135. target: zuul-fingergw
  136. - context: .
  137. repository: zuul/zuul-merger
  138. target: zuul-merger
  139. - context: .
  140. repository: zuul/zuul-scheduler
  141. target: zuul-scheduler
  142. - context: .
  143. repository: zuul/zuul-web
  144. target: zuul-web
  145. - job:
  146. name: zuul-upload-image
  147. parent: opendev-upload-docker-image
  148. description: Build Docker images and upload to Docker Hub.
  149. allowed-projects: zuul/zuul
  150. requires:
  151. - python-builder-3.7-container-image
  152. - python-base-3.7-container-image
  153. provides: zuul-container-image
  154. secrets:
  155. name: docker_credentials
  156. secret: zuul-dockerhub
  157. pass-to-parent: true
  158. vars: *zuul_image_vars
  159. - job:
  160. name: zuul-promote-image
  161. parent: opendev-promote-docker-image
  162. description: Promote previously uploaded Docker images.
  163. allowed-projects: zuul/zuul
  164. secrets:
  165. name: docker_credentials
  166. secret: zuul-dockerhub
  167. pass-to-parent: true
  168. nodeset:
  169. nodes: []
  170. vars: *zuul_image_vars
  171. - job:
  172. name: zuul-build-python-release
  173. parent: build-python-release
  174. pre-run: playbooks/release/pre.yaml
  175. vars: &zuul_build_vars
  176. release_python: python3
  177. - job:
  178. name: zuul-release-python
  179. parent: opendev-release-python
  180. pre-run: playbooks/release/pre.yaml
  181. vars: *zuul_build_vars
  182. - project:
  183. vars:
  184. node_version: 14
  185. check:
  186. jobs:
  187. - zuul-build-image
  188. - zuul-tox-docs
  189. - tox-linters:
  190. vars:
  191. tox_install_bindep: false
  192. - tox-py35:
  193. irrelevant-files:
  194. - zuul/cmd/migrate.py
  195. - playbooks/zuul-migrate/.*
  196. nodeset: ubuntu-xenial
  197. timeout: 4800 # 80 minutes
  198. vars:
  199. test_setup_environment:
  200. ZUUL_TEST_ROOT: /tmp/zuul-test
  201. tox_environment:
  202. ZUUL_TEST_ROOT: /tmp/zuul-test
  203. - tox-py38:
  204. irrelevant-files:
  205. - zuul/cmd/migrate.py
  206. - playbooks/zuul-migrate/.*
  207. timeout: 4800 # 80 minutes
  208. nodeset: ubuntu-bionic
  209. vars:
  210. test_setup_environment:
  211. ZUUL_TEST_ROOT: /tmp/zuul-test
  212. tox_environment:
  213. ZUUL_TEST_ROOT: /tmp/zuul-test
  214. - zuul-build-dashboard-openstack-whitelabel
  215. - zuul-build-dashboard-software-factory
  216. - zuul-build-dashboard-opendev
  217. - nodejs-run-lint:
  218. vars:
  219. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  220. - nodejs-run-test:
  221. vars:
  222. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  223. success-url: 'npm/reports/bundle.html'
  224. files:
  225. - web/.*
  226. - zuul-stream-functional-2.7
  227. - zuul-stream-functional-2.8
  228. - zuul-stream-functional-2.9
  229. - zuul-tox-remote:
  230. timeout: 2700 # 45 minutes
  231. - zuul-quick-start:
  232. requires: nodepool-container-image
  233. dependencies: zuul-build-image
  234. - nodepool-zuul-functional:
  235. voting: false
  236. - zuul-build-python-release
  237. gate:
  238. jobs:
  239. - zuul-upload-image
  240. - zuul-tox-docs
  241. - tox-linters:
  242. vars:
  243. tox_install_bindep: false
  244. - tox-py35:
  245. irrelevant-files:
  246. - zuul/cmd/migrate.py
  247. - playbooks/zuul-migrate/.*
  248. nodeset: ubuntu-xenial
  249. timeout: 4800 # 80 minutes
  250. vars:
  251. test_setup_environment:
  252. ZUUL_TEST_ROOT: /tmp/zuul-test
  253. tox_environment:
  254. ZUUL_TEST_ROOT: /tmp/zuul-test
  255. - tox-py38:
  256. irrelevant-files:
  257. - zuul/cmd/migrate.py
  258. - playbooks/zuul-migrate/.*
  259. timeout: 4800 # 80 minutes
  260. nodeset: ubuntu-bionic
  261. vars:
  262. test_setup_environment:
  263. ZUUL_TEST_ROOT: /tmp/zuul-test
  264. tox_environment:
  265. ZUUL_TEST_ROOT: /tmp/zuul-test
  266. - zuul-build-dashboard
  267. - nodejs-run-lint:
  268. vars:
  269. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  270. - nodejs-run-test:
  271. vars:
  272. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  273. success-url: 'npm/reports/bundle.html'
  274. files:
  275. - web/.*
  276. - zuul-stream-functional-2.7
  277. - zuul-stream-functional-2.8
  278. - zuul-stream-functional-2.9
  279. - zuul-tox-remote:
  280. timeout: 2700 # 45 minutes
  281. - zuul-quick-start:
  282. requires: nodepool-container-image
  283. dependencies: zuul-upload-image
  284. - zuul-build-python-release
  285. promote:
  286. jobs:
  287. - zuul-promote-image
  288. - zuul-promote-docs
  289. - opendev-promote-python:
  290. vars:
  291. download_artifact_job: zuul-build-python-release
  292. - opendev-promote-javascript-deployment:
  293. vars:
  294. download_artifact_job: zuul-build-dashboard
  295. release:
  296. jobs:
  297. - zuul-release-python
  298. - zuul-publish-tox-docs