be50a6ca42
Freze Zuul job variables when starting a build so that jinja templates can not be used to expose secrets. The values will be frozen by running a playbook with set_fact, and that playbook will run without access to secrets. After the playbook completes, the frozen variables are read from and then removed from the fact cache. They are then supplied as normal inventory variables for any trusted playbooks or playbooks with secrets. The regular un-frozen variables are used for all other untrusted playbooks. Extra-vars are now only used to establish precedence among all Zuul job variables. They are no longer passed to Ansible with the "-e" command line option, as that level of precedence could also be used to obtain secrets. Much of this work is accomplished by "squashing" all of the Zuul job, host, group, and extra variables into a flat structure for each host in the inventory. This means that much of the variable precedence is now handled by Zuul, which then gives Ansible variables as host vars. The actual inventory files will be much more verbose now, since each host will have a copy of every "all" value. But this allows the freezing process to be much simpler. When writing the inventory for the setup playbook, we now use the !unsafe YAML tag which is understood by Ansible to indicate that it should not perform jinja templating on variables. This may help to avoid any mischief with templated variables since they have not yet been frozen. Also, be more strict about what characters are allowed in ansible variable names. We already checked job variables, but we didn't verify that secret names/aliases met the ansible variable requirements. A check is added for that (and a unit test that relied on the erroneous behavior is updated). Story: 2008664 Story: 2008682 Change-Id: I04d8b822fda6628e87a4a57dc368f20d84ae5ea9 |
||
|---|---|---|
| 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 | ||
| 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 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.