9eef4e532a
Normally, if a change is made to a job configuration, we want to ignore the file matchers and run the job so that we can see the update in practice. However, we don't want to do so if the *only* change to the job configuration is the file matchers. The result is no different than before, and running the job tells us nothing about the value of the change. This behavior was already the case, but due to a bug. This change both fixes the bug and intentionally restores the behavior. The bug that is corrected is that when variants were applied, the actual file matchers attached to the frozen job were updated, but not their string/list representation (stored in the '_files' and '_irrelevant_files' attributes). This change moves those attributes to the list of context attributes (which are automatically copied on inheritance) -- the same as the actual matcher attributes. We also do the same for the '_branches' attribute (the text version of the branch matcher). These changes make the serialized form of the frozen job (which is returned by the web api) more accurate. And in the case of the files matchers, causes Zuul to correctly detect that the job has changed when they are updated. To restore the current (accidental but desired) behavior, we now pop the files and irrelevant-files keys from the serialized representation of the job before comparison when deciding whether to run the job during a config update. This means that it will only run if something other than a files matcher is changed. This change also removes the _implied_branch job attribute because it is no longer used anywhere (implied branches now arrive via projects and project templates). Change-Id: Id1d595873fe87ca980b2f33832f55542f9e5d496 |
||
|---|---|---|
| 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://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 #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 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.