516780f9e7
Given two PRs with B depending on A which are enqueued in gate, A is closed and then immediately reopened. This sequence of events will currently dequeue A and then immediately enqueue it behind B. Since the check for whether a dependency is already in the queue doesn't care if it's ahead or behind the current change, we'll not dequeue B and the content of builds executed by B will not include A. This change updates the check to determine if a change is already in the queue to only check for changes ahead of it. This causes B to be correctly dequeued in the next pipeline pass. This behavior is correct, but isn't always intuitive or consistent. If the time between closing and reopening a change is long enough for a pipeline process, then both changes will be enqueued by the reopening (because we check for changes needing enqueued changes and enqueue them behind). But if both events are processed in a single pipeline run, then the removal of B happens after the re-enqueue of A which means that it won't be re-added. To correct this, whenever we remove abandoned changes, we will also remove changes behind them that depend on the removed abandoned changes at the same time. This means that in our scenario above, the re-enqueue happens under the same conditions as the original enqueue, and both A and B are re-enqueued. Co-Authored-By: James E. Blair <jim@acmegating.com> Change-Id: Ia1d79bccb9ea39e486483283611601aa23903000 |
||
|---|---|---|
| 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.