802c5a8ca6
In the case of circular dependencies with job deduplication, we arbitrarily pick one of the changes as the zuul change (to use when setting the zuul.change job variable and friends). In theory, it shouldn't matter which change we use, but in practice, users may be surprised if it is something other than the triggering change. Since it doesn't really matter to Zuul, let's set the zuul change to the triggering change when possible. It still needs to be one of the changes for the job, so if the triggering change itself doesn't actually run the job (easily possible if the job is only run on dependent changes), then we will fall back to the current behavior. And of course the change must be one of the item's changes, so in the case of linear dependencies, we're not going to start setting it to some other queue item's change. If we are unable to set it to the triggering change, then the behavior remains undefined beyond setting it to one of the job's changes arbitrarily. Included in this change is a cleanup of a no-longer-needed api migration from 12->13 related to EventInfo objects that was missed due to a missing MODEL_API tag. Information about the triggering change is added to the EventInfo object to implement this feature. Because the fallback behavior and the model upgrade behavior are the same, we don't need to add any conditional api behavior or upgrade testing -- in both cases we will simply use the current behavior. Change-Id: Iee5a7d975fea1f7491b652c406c24d73ada7a1a1 |
||
|---|---|---|
| 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 | ||
| noxfile.py | ||
| reno.yaml | ||
| 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 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.