bd7a5d47bf
The "current" provides/requires test (which is supposed to test live changes) was inadvertently following the SQL code path in some cases. The test has been updated to include a third job which continues running until the end of the test to ensure that the changes remain in the pipeline the entire time. It, and the SQL version, have been extended with one more change to illustrate a bug where artifact data were being included twice. This was because the data collection method has two recursion points: a) if it is called on a non-live change and it finds a live version of the same change, it recursively calls itself on the non-live version of the same change. Essentially, it "switches" to that version of the change and continues. b) at the end of normal processing of a change, it recurses "up" the queue to the next change ahead. The (a) case did not return in some cases, so in those cases, it would "switch" to a change, add its data, recurse up the queue, then, after unrolling back to the point of the switch, would then recurse up the queue again in case (b). The solution is to avoid recursing up the queue in the (a) case and allow it only in the (b) case -- that is, we only walk up the queue of dependent changes for the original change. Finally, the artifacts were being returned in reverse order -- it is more useful for them to be returned such that the latest version of a given artifact is returned last so that competing versions are overwritten in the correct order. Change-Id: I41ac336c1bc776609645e3662003f2df076dd1d5 |
||
|---|---|---|
| doc | ||
| etc | ||
| playbooks | ||
| releasenotes/notes | ||
| tests | ||
| tools | ||
| web | ||
| zuul | ||
| .coveragerc | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| COPYING | ||
| Dockerfile | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| TESTING.rst | ||
| bindep.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
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 in the #zuul channel on Freenode IRC.
Contributing
To browse the latest code, see: https://git.zuul-ci.org/cgit/zuul/tree/ To clone the latest code, use git clone https://git.zuul-ci.org/zuul
Bugs are handled at: https://storyboard.openstack.org/#!/project/openstack-infra/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.openstack.org
After creating a Gerrit account, use git review to submit patches. Example:
# Do your commits
$ git review
# Enter your username if promptedJoin #zuul on Freenode 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 v3 requires Python 3. It does not support Python 2.
As Ansible is used for the execution of jobs, it's important to note
that while Ansible does support Python 3, not all of Ansible's modules
do. Zuul currently sets ansible_python_interpreter to
python2 so that remote content will be executed with Python 2.