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
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312
  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.6
  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.6
  34. vars:
  35. zuul_ansible_version: 2.6
  36. - job:
  37. name: zuul-stream-functional-2.7
  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.7
  42. vars:
  43. zuul_ansible_version: 2.7
  44. - job:
  45. name: zuul-stream-functional-2.8
  46. parent: zuul-stream-functional
  47. # Force executor to use same Ansible version as "controller" node so
  48. # that the inventory.yaml file will be correct for that version.
  49. ansible-version: 2.8
  50. vars:
  51. zuul_ansible_version: 2.8
  52. - job:
  53. name: zuul-stream-functional-2.9
  54. parent: zuul-stream-functional
  55. success-url: 'http://zuul.opendev.org/t/zuul/build/{build.uuid}'
  56. failure-url: 'http://zuul.opendev.org/t/zuul/build/{build.uuid}'
  57. vars:
  58. zuul_ansible_version: 2.9
  59. - job:
  60. name: zuul-tox-remote
  61. parent: tox
  62. vars:
  63. tox_envlist: remote
  64. tox_environment:
  65. ZUUL_SSH_KEY: /home/zuul/.ssh/id_rsa
  66. ZUUL_REMOTE_IPV4: "{{ nodepool.interface_ip }}"
  67. ZUUL_REMOTE_KEEP: "true"
  68. - job:
  69. name: zuul-build-dashboard
  70. parent: build-javascript-content
  71. success-url: 'npm/html/'
  72. files:
  73. - web/.*
  74. - playbooks/dashboard/.*
  75. vars:
  76. javascript_content_dir: "../zuul/web/static"
  77. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  78. zuul_api_url: https://zuul.openstack.org
  79. node_version: 10
  80. run: playbooks/dashboard/run.yaml
  81. - job:
  82. name: zuul-build-dashboard-multi-tenant
  83. parent: zuul-build-dashboard
  84. vars:
  85. zuul_api_url: https://softwarefactory-project.io/zuul
  86. node_version: 10
  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. description: Run the commands in the Zuul quick-start documentation.
  94. run: playbooks/quick-start/run.yaml
  95. post-run: playbooks/quick-start/post.yaml
  96. requires: docker-image
  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. vars: &zuul_image_vars
  122. docker_images:
  123. - context: .
  124. repository: zuul/zuul
  125. target: zuul
  126. - context: .
  127. repository: zuul/zuul-executor
  128. target: zuul-executor
  129. - context: .
  130. repository: zuul/zuul-fingergw
  131. target: zuul-fingergw
  132. - context: .
  133. repository: zuul/zuul-merger
  134. target: zuul-merger
  135. - context: .
  136. repository: zuul/zuul-scheduler
  137. target: zuul-scheduler
  138. - context: .
  139. repository: zuul/zuul-web
  140. target: zuul-web
  141. - job:
  142. name: zuul-upload-image
  143. parent: opendev-upload-docker-image
  144. description: Build Docker images and upload to Docker Hub.
  145. allowed-projects: zuul/zuul
  146. secrets:
  147. name: docker_credentials
  148. secret: zuul-dockerhub
  149. pass-to-parent: true
  150. vars: *zuul_image_vars
  151. - job:
  152. name: zuul-promote-image
  153. parent: opendev-promote-docker-image
  154. description: Promote previously uploaded Docker images.
  155. allowed-projects: zuul/zuul
  156. secrets:
  157. name: docker_credentials
  158. secret: zuul-dockerhub
  159. pass-to-parent: true
  160. nodeset:
  161. nodes: []
  162. vars: *zuul_image_vars
  163. - job:
  164. name: zuul-build-python-release
  165. parent: build-python-release
  166. pre-run: playbooks/release/pre.yaml
  167. vars: &zuul_build_vars
  168. node_version: 10
  169. release_python: python3
  170. - job:
  171. name: zuul-release-python
  172. parent: opendev-release-python
  173. pre-run: playbooks/release/pre.yaml
  174. vars: *zuul_build_vars
  175. - project:
  176. check:
  177. jobs:
  178. - zuul-build-image
  179. - zuul-tox-docs
  180. - tox-pep8
  181. - tox-py35:
  182. irrelevant-files:
  183. - zuul/cmd/migrate.py
  184. - playbooks/zuul-migrate/.*
  185. nodeset: ubuntu-xenial
  186. timeout: 4800 # 80 minutes
  187. vars:
  188. test_setup_environment:
  189. ZUUL_TEST_ROOT: /tmp/zuul-test
  190. tox_environment:
  191. ZUUL_TEST_ROOT: /tmp/zuul-test
  192. - tox-py37:
  193. irrelevant-files:
  194. - zuul/cmd/migrate.py
  195. - playbooks/zuul-migrate/.*
  196. timeout: 4800 # 80 minutes
  197. nodeset: ubuntu-bionic
  198. vars:
  199. test_setup_environment:
  200. ZUUL_TEST_ROOT: /tmp/zuul-test
  201. tox_environment:
  202. ZUUL_TEST_ROOT: /tmp/zuul-test
  203. - zuul-build-dashboard
  204. - zuul-build-dashboard-multi-tenant
  205. - nodejs-npm-run-lint:
  206. vars:
  207. node_version: 10
  208. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  209. - nodejs-npm-run-test:
  210. vars:
  211. node_version: 10
  212. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  213. success-url: 'npm/reports/bundle.html'
  214. files:
  215. - web/.*
  216. - zuul-stream-functional-2.6
  217. - zuul-stream-functional-2.7
  218. - zuul-stream-functional-2.8
  219. - zuul-stream-functional-2.9
  220. - zuul-tox-remote:
  221. timeout: 2700 # 45 minutes
  222. - zuul-quick-start:
  223. dependencies: zuul-build-image
  224. - nodepool-zuul-functional:
  225. voting: false
  226. - zuul-build-python-release
  227. - build-javascript-content-tarball:
  228. vars:
  229. node_version: 10
  230. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  231. create_tarball_directory: build
  232. gate:
  233. jobs:
  234. - zuul-upload-image
  235. - zuul-tox-docs
  236. - tox-pep8
  237. - tox-py35:
  238. irrelevant-files:
  239. - zuul/cmd/migrate.py
  240. - playbooks/zuul-migrate/.*
  241. nodeset: ubuntu-xenial
  242. timeout: 4800 # 80 minutes
  243. vars:
  244. test_setup_environment:
  245. ZUUL_TEST_ROOT: /tmp/zuul-test
  246. tox_environment:
  247. ZUUL_TEST_ROOT: /tmp/zuul-test
  248. - tox-py37:
  249. irrelevant-files:
  250. - zuul/cmd/migrate.py
  251. - playbooks/zuul-migrate/.*
  252. timeout: 4800 # 80 minutes
  253. nodeset: ubuntu-bionic
  254. vars:
  255. test_setup_environment:
  256. ZUUL_TEST_ROOT: /tmp/zuul-test
  257. tox_environment:
  258. ZUUL_TEST_ROOT: /tmp/zuul-test
  259. - zuul-build-dashboard
  260. - nodejs-npm-run-lint:
  261. vars:
  262. node_version: 10
  263. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  264. - nodejs-npm-run-test:
  265. vars:
  266. node_version: 10
  267. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  268. success-url: 'npm/reports/bundle.html'
  269. files:
  270. - web/.*
  271. - zuul-stream-functional-2.6
  272. - zuul-stream-functional-2.7
  273. - zuul-stream-functional-2.8
  274. - zuul-stream-functional-2.9
  275. - zuul-tox-remote:
  276. timeout: 2700 # 45 minutes
  277. - zuul-quick-start:
  278. dependencies: zuul-upload-image
  279. - zuul-build-python-release
  280. - build-javascript-content-tarball:
  281. vars:
  282. node_version: 10
  283. zuul_work_dir: "{{ zuul.project.src_dir }}/web"
  284. create_tarball_directory: build
  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-content
  293. release:
  294. jobs:
  295. - zuul-release-python
  296. - zuul-publish-tox-docs