8bcfb8bc4a
The current SQL query will not correctly limit the number of buildsets when some of the buildsets are related to multiple refs (circular dependencies). The problem is that LIMTI works on number of rows, but we want to limit only on the number of buildsets. This corrects the problem by using a subquery to identify the distinct buildsets, limiting that, and then querying for all of the information about those buildsets. This also updates the methods which perform the same function for builds, even though we are not yet seeing an issue in practice. It is theoretically possible to call the getBuilds method with 'provides' and 'limit' arguments, which would produce the same problem as the buildsets query. That is not possible in practice, as the REST API doesn't support provides, and the scheduler which does pass the provides argument doesn't pass limit. However, that could easily change in the future. Additionally, this future-proofs us if we add more queryable one-to-many relationships to builds in the future (such as if we linked builds to multiple refs). Also, it's easier to maintain these methods if they follow the same pattern. There does not appear to be a performance loss in either mysql or postgres with local testing on large data sets. There may actually be an improvement (but it's within the margin of error, so hard to say). The index hints previously needed for mysql appear to no longer be necessary and are removed. Change-Id: Ib19e4cb8171f5d4d2873fb6b9c0301eb5d4ee43d Co-Authored-By: James E. Blair <jim@acmegating.com> |
||
|---|---|---|
| doc | ||
| etc | ||
| playbooks | ||
| releasenotes/notes | ||
| tests | ||
| tools | ||
| web | ||
| zuul | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| bindep.txt | ||
| COPYING | ||
| Dockerfile | ||
| LICENSE | ||
| MANIFEST.in | ||
| noxfile.py | ||
| README.rst | ||
| reno.yaml | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| TESTING.rst | ||
| tox.ini | ||
Zuul
Zuul is a project gating system.
The latest documentation for Zuul v3 is published at: https://zuul-ci.org/docs/zuul/
If you are looking for the Edge routing service named Zuul that is related to Netflix, it can be found here: https://github.com/Netflix/zuul
If you are looking for the Javascript testing tool named Zuul, it can be found here: https://github.com/defunctzombie/zuul
Getting Help
There are two Zuul-related mailing lists:
- zuul-announce
-
A low-traffic announcement-only list to which every Zuul operator or power-user should subscribe.
- zuul-discuss
-
General discussion about Zuul, including questions about how to use it, and future development.
You will also find Zuul developers on Matrix <https://matrix.to/#/#zuul:opendev.org>.
Contributing
To browse the latest code, see: https://opendev.org/zuul/zuul To clone the latest code, use git clone https://opendev.org/zuul/zuul
Bugs are handled at: https://storyboard.openstack.org/#!/project/zuul/zuul
Suspected security vulnerabilities are most appreciated if first reported privately following any of the supported mechanisms described at https://zuul-ci.org/docs/zuul/user/vulnerabilities.html
Code reviews are handled by gerrit at https://review.opendev.org
After creating a Gerrit account, use git review to submit patches. Example:
# Do your commits
$ git review
# Enter your username if promptedJoin us on Matrix to discuss development or usage.
License
Zuul is free software. Most of Zuul is licensed under the Apache License, version 2.0. Some parts of Zuul are licensed under the General Public License, version 3.0. Please see the license headers at the tops of individual source files.
Python Version Support
Zuul requires Python 3. It does not support Python 2.
Since Zuul uses Ansible to drive CI jobs, Zuul can run tests anywhere Ansible can, including Python 2 environments.