summaryrefslogtreecommitdiff
path: root/tests/unit/test_web_urls.py
Commit message (Collapse)AuthorAgeFilesLines
* Remove rpcclient from connection test fixturesJames E. Blair2022-01-171-1/+1
| | | | | | | There are no uses of the rpc client in tests now, remove the initialization and parameters. Change-Id: I2d22fa73138c8cc2db96f78ecbc2dc3792cdd8bb
* Initialize ZooKeeper connection in server rather than in cmd classesFelix Edel2021-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | Currently, the ZooKeeper connection is initialized directly in the cmd classes like zuul.cmd.scheduler or zuul.cmd.merger and then passed to the server instance. Although this makes it easy to reuse a single ZooKeeper connection for multiple components in the tests it's not very realistic. A better approach would be to initialize the connection directly in the server classes so that each component has its own connection to ZooKeeper. Those classes already get all necessary parameters, so we could get rid of the additional "zk_client" parameter. Furthermore it would allow us to use a dedicated ZooKeeper connection for each component in the tests which is more realistic than sharing a single connection between all components. Change-Id: I12260d43be0897321cf47ef0c722ccd74599d43d
* Use ZooKeeperClient.fromConfig in testsJames E. Blair2021-02-221-1/+1
| | | | | | | | | | | | | | | To make the tests more like running the apps, use fromConfig in the tests rather than directly creating a client from a string connection description. Note that since fromConfig requires TLS and the tests don't use it, a temporary argument has been added to that method to allow non-tls connections; it's only used within the test suite. In future changes, we can configure the tests to use TLS connections, remove the argument, and then move client instantiation into the server classes themselves (which will remove additional differences between test and production startup code). Change-Id: Ic45c0e60c464ed8eeb44cb32bab039403f73ec69
* Mandatory Zookeeper connection for ZuulWeb in testsJan Kubovy2021-02-151-1/+1
| | | | | | This is needed for change: I532dfb5af56a5d3074a808c4cf4a6854285636e8 Change-Id: Ice363c53b53ed90aec2f61849a4fea0f490b06a7
* Separate connection registries in testsJan Kubovy2020-10-131-2/+5
| | | | | | | | | Each scheduler in tests needs its own connection registries. This change only affects tests. Change-Id: I2ad188cf5a72c46f7486c23ab653ff574123308b Story: 2007192
* Update to create-react-app 3.4.1Monty Taylor2020-05-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | While trying to figure out why the ansi patch wouldn't build it emerged that we're now 2 major releases behind on create-react-app. Update create-react-app to the latest 3.4.1. This also updates react to 16.13, and updates eslint globals processing so that we don't have to declare globals in headers when we've declared them already in the eslint file. Finally, although this doesn't do it, create-react-app 3 has support for typescript, so if we want we can start migrating files to .ts or .tsx extensions and start doing typing in them. Pin nanoid to v2 until such a time as create-react-app can be updated to 3.4.2 which is needed ot handle .cjs extensions being used by nanoid. Change-Id: Ibc69bef605a62e4fdd2ebba33d9d1b822e7dfeba
* Add command processor to zuul-webTobias Henkel2019-06-211-1/+1
| | | | | | | | | Zuul uses the command processor for most components to send commands to a running service. We should add this to zuul-web as well starting with the stop command. In a later change we'll add commands for starting/stopping a repl server. Change-Id: I1d02ec30341be0890afb332dcf9f32f10a52ead5
* Revert "web: upgrade react and react-scripts to ^2.0.0"David Shrewsbury2019-05-161-2/+0
| | | | | | | | Dashboard appears to be broken by this. JS errors at: http://paste.openstack.org/show/751488/ This reverts commit 9a4cd7a0264ffc936f43e474131e9b6da0cc1499. Change-Id: I881b28815237cf4b0bc151a267a49162613df72e
* web: upgrade react and react-scripts to ^2.0.0Tristan Cacqueray2019-05-021-0/+2
| | | | | | | | | | - react-scripts>2.0.0 supports requirements written in newer javascript. - eslint=5.6.0 is required by react-scripts>2.0.0 - update redux, patternfly-react and react to latest release - default browserslist is added to the packages.json - fix new eslint error Change-Id: Ibee14604b364ce8d4133bcc409a70402bdde9df0
* Fix flake 3.6.0 warningsAndreas Jaeger2018-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | flake 3.6.0 introduces a couple of new tests, handle them in the zuul base: * Disable "W504 line break after binary operator", this is a new warning with different coding style. * Fix "F841 local variable 'e' is assigned to but never used" * Fix "W605 invalid escape sequence" - use raw strings for regexes. * Fix "F901 'raise NotImplemented' should be 'raise NotImplementedError'" * Ignore "E252 missing whitespace around parameter equals" since it reports on parameters like: def makeNewJobs(self, old_job, parent: Job=None): Change "flake8: noqa" to "noqa" since "flake8: noqa" is a file level noqa and gets ignored with flake 3.6.0 if it's not at beginning of line - this results in many warnings for files ./zuul/driver/bubblewrap/__init__.py and ./zuul/cmd/migrate.py. Fix any issues there. Change-Id: Ia79bbc8ac0cd8e4819f61bda0091f4398464c5dc
* Revert "Revert "web: rewrite interface in react""Tristan Cacqueray2018-10-061-8/+8
| | | | | | This reverts commit 3dba813c643ec8f4b3323c2a09c6aecf8ad4d338. Change-Id: I233797a9b4e3485491c49675da2c2efbdba59449
* Revert "web: rewrite interface in react"James E. Blair2018-09-291-8/+8
| | | | | | | | | | | Revert "Fix publish-openstack-javascript-content" This reverts commit ca199eb9dbb64e25490ee5803e4f18c91f34681d. This reverts commit 1082faae958bffa719ab333c3f5ae9776a8b26d7. This appears to remove the tarball publishing system that we rely on. Change-Id: Id746fb826dfc01b157c5b772adc1d2991ddcd93a
* web: rewrite interface in reactTristan Cacqueray2018-09-271-8/+8
| | | | | | | | | | This change rewrites the web interface using React: http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-August/000528.html Depends-On: https://review.openstack.org/591964 Change-Id: Ic6c33102ac3da69ebd0b8e9c6c8b431d51f3cfd4 Co-Authored-By: Monty Taylor <mordred@inaugust.com> Co-Authored-By: James E. Blair <jeblair@redhat.com>
* Remove unecessary shebang and exec bitFabien Boucher2018-07-261-2/+0
| | | | Change-Id: I54de68b11f055a9269ca5efb8a57f81d57f9d55f
* Fix zuul-web sql connectionsJames E. Blair2018-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | A recent change to scope sql connections to tenants was incorrect because it assumed zuul-web would have access to a tenant's layout, but that is only in the zuul-scheduler's memory. Instead, this change causes zuul-web to perform an RPC call to the scheduler to ask which connection to use before performing sql queries. This slipped through testing because the zuul web test fixture used the same connection registry object as the scheduler, and therefore *was* able to access data which normally would not be available to it. This updates the zuul web test fixture to use a separate connection registry. Also, because zuul-web doesn't need any other kinds of connections at the moment, add a facility to allow it to only load sql connections, so that it doesn't do anything with the gerrit or github drivers. Change-Id: Iac6d8c6960f4a31eb2f78511664b704758e41687
* Move SQL web handler to driverJames E. Blair2018-05-311-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only rest API endpoint that uses sql queries is /api/tenant/{tenant}/builds. There's no connection in there, which means it doesn't make sense for that to be attached to a sql connection (which is currently the case). Moreover, it doesn't make sense for *every* tenant's endpoint to be attached to the *same* connection. In other words, the current situation only allows for a single sql connection system-wide, even if someone is using different connections per tenant. Moving the handler for the endpoint into the sql driver means that it can dispatch the query to the appropriate connection for a given tenant (since a tenant is always implied by the REST endpoint). Moreover, the *rest* of the system actually allows multiple connections within a single tenant, and we should support that here, but I don't immediately have a solution of how to handle pagination across queries that span multiple connections. This is an improvement in that it is now tenant-scoped, but it's not ideal. This also removes the (undocumented!) sql_connection_name config file option. It also uses the tenant name from the path to constructe the query so that it always includes the correct tenant (this eliminates the inadvertant ability for one tenant to query another tenant's builds). The internal API here isn't great, but it will get cleaned up in the next patch which converts to cherrypy. Change-Id: Ie1f19f0b392d4c010ef43dc6220ff1c8667f5a4a
* Reorganize REST API and dashboard urlsMonty Taylor2018-03-281-4/+22
| | | | | | | | | | | | | | | | | | | | The existing structure with the API and HTML interleaved makes it hard to have apache do html offloading for whitelabeled deploys (like openstack's) where the api and web are served from the same host. Similarly, the tenant selector in the url for the html content being bare and not prefixed by anything makes it harder to pull routing information javascript-side. Introduce an 'api' prefix to the REST API calls so that we can apply rewrite rules differently for things starting with /api than things that don't. Add the word 'tenant' before each tenant subpath. Also add a '/t/' to the url for the html, so that we have anchors for routing regexes but the urls don't get too long and unweildy. Finally, also add /key as a prefix to the key route for similar reasons. Change-Id: I0cbbf6f1958e91b5910738da9b4fb4c563d48dd4
* Use yarn and webpack to manage zuul-web javascriptMonty Taylor2018-03-041-0/+101
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>