Jobs not automatically requeued when dependencies are approved
Bug #1354464 reported by
Matthew Booth
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Core Infrastructure |
Fix Released
|
Medium
|
Unassigned | ||
Bug Description
Change Y depends on Change X. Neither have been approved.
Initial state:
1. X (-A) -> Y (-A)
Y is approved:
2. X (-A) -> Y (+A)
Jenkins immediately runs a check job on Y and gives it +1. It doesn't run a gate job on Y, though, because its dependencies are not met.
X is approved:
3. X (+A) -> Y (+A)
Jenkins immediately runs both check and gate jobs on X, and merges it. However, it does not run a gate job on Y. There is no way I am aware of to kick Jenkins into action on Y other than to give it a spurious recheck.
| Changed in openstack-ci: | |
| status: | New → Confirmed |
| importance: | Undecided → Medium |
| milestone: | none → juno |
Revision history for this message
| Jeremy Stanley (fungi) wrote | #1 |
Revision history for this message
| James E. Blair (corvus) wrote | #2 |
| Changed in openstack-ci: | |
| status: | Confirmed → Fix Released |
Revision history for this message
| Matthew Booth (mbooth-9) wrote | #3 |
To post a comment you must log in.
Agreed, this is a (perhaps not widely) known drawback to our "clean check" implementation. The underlying problem is that in this case change Y did not have a new enough +1 from the "Jenkins" user (it was older than 24 hours) and so it did not meet the enqueuing criteria for the gate pipeline.
To solve this we'd probably need some way of instructing Zuul to rerun check jobs on already approved child changes whose last check was over the enqueuing threshold, triggered on some internal event (perhaps when the parent change is approved).
Thanks for opening the bug--we should use it to track any eventual solution to this unintended design implication.