| @jjbeckman:matrix.org | Thanks for the clarification. I was able to narrow the problem down to API calls to the k8s master node randomly failing, and beefing up the master node specs seems to have solved the issue. | 09:44 |
|---|---|---|
| -@gerrit:opendev.org- daniel.pawlik https://matrix.to/#/@dpawlik:matrix.org proposed: [zuul/zuul] 889314: Change start_time and end_time field type to integer; add new fields https://review.opendev.org/c/zuul/zuul/+/889314 | 11:53 | |
| -@gerrit:opendev.org- daniel.pawlik https://matrix.to/#/@dpawlik:matrix.org proposed: [zuul/zuul] 889314: Change start_time and end_time field type to integer; add new fields https://review.opendev.org/c/zuul/zuul/+/889314 | 11:55 | |
| -@gerrit:opendev.org- daniel.pawlik https://matrix.to/#/@dpawlik:matrix.org proposed: [zuul/zuul] 889314: Change start_time and end_time field type to integer; add new fields https://review.opendev.org/c/zuul/zuul/+/889314 | 13:06 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul] 890209: Update TESTING doc for nox https://review.opendev.org/c/zuul/zuul/+/890209 | 13:21 | |
| @tony.breeds:matrix.org | corvus: Given that https://zuul-ci.org/docs/zuul-jobs/latest/mirror.html isn't implemented yet, is it changeable? | 17:51 |
| @tony.breeds:matrix.org | I started implemening in and it feels like "wheel" could/should be part of the pypi element rather than stand alone | 17:52 |
| @jim:acmegating.com | tony.breeds: sure thing -- i bet both pypi and our understanding of pypi/wheels have changed since then too. maybe propose a docs change with some explanation/examples for your new idea and we can ask folks to review that | 18:30 |
| @tony.breeds:matrix.org | Sounds good. | 18:38 |
| @fungicide:matrix.org | random brainstorming... openstack often has deep dependent pipeline queues, and from time to time a change author or reviewer would like to dequeue a particular change from that pipeline. right now they can accomplish it in a couple of ways, by temporarily switching the change to "abandoned" state in gerrit, or pushing a new revision, but there's interest in more lightweight ways to do that which are less disruptive to the related code review. am i correct in remembering that we don't have the ability to specify arbitrary dequeue trigger conditions on a pipeline (like the reverse of an enqueuing trigger)? | 19:30 |
| @fungicide:matrix.org | or maybe zuul could notice earlier when merge conditions are no longer met and dequeue the change at that time rather than waiting until it's time to try to merge it? | 19:32 |
| @fungicide:matrix.org | for example, a change in wip state isn't mergeable, so in theory if zuul sees the event that transitions that change to wip it could infer that the change should be dequeued from dependent merge pipelines? | 19:33 |
| @fungicide:matrix.org | but theoretically, votes on labels that would prevent merging could be seen as a similar indicator | 19:37 |
| @fungicide:matrix.org | (workflow -1 or code review -2 in our convention) | 19:37 |
| @fungicide:matrix.org | (or removal of a workflow +1 approval) | 19:38 |
| @jim:acmegating.com | fungi: the pipeline `require` attribute is close, but is still only evaluated on enqueue. it could probably be changed to be evaluated continuously, but it'd be a behavior change. | 19:39 |
| @jim:acmegating.com | fungi: another option would be to give people authenticated web ui access so they can click the dequeue button. | 19:40 |
| @fungicide:matrix.org | yeah, i thought about the latter solution of course, but it means either giving that access to hundreds of people (and dealing with account management) or expecting them to ask someone every time they want a change dequeued, at which point they'll probably take the easier way out and use abandon or trivial revision options | 19:41 |
| @jim:acmegating.com | fungi: i'm pretty sure submit requirements are evaluated continuously though | 19:45 |
| @jim:acmegating.com | fungi: i just tried it with https://review.opendev.org/890065 | 19:46 |
| @fungicide:matrix.org | oh neat, so code review -2 works. i wonder why workflow -1 didn't work similarly when people tried it | 19:47 |
| @jim:acmegating.com | fungi: that wasn't code-review -2, that was "remove all reviews". | 19:48 |
| @jim:acmegating.com | fungi: i re-approved it if you want to try leaving a cr-2 or w-1 on it | 19:50 |
| @fungicide:matrix.org | ahh | 19:50 |
| @fungicide:matrix.org | yeah, workflow -1 also dequeued it | 19:52 |
| @jim:acmegating.com | so i think for the specific case of a dependent pipeline, that handles the use case, yeah? | 19:52 |
| @fungicide:matrix.org | so maybe it's down to how the gate pipeline for our openstack tenant is configured, if it wasn't working the same there | 19:53 |
| @fungicide:matrix.org | oh, or, as i just discovered, they were testing on a change in an independent pipeline and assuming the dependent pipeline would behave similarly | 19:56 |
| @fungicide:matrix.org | is continuous evaluation of submit requirements a relatively new behavior? | 19:57 |
| @jim:acmegating.com | i wanna say < 1 year; i could look up the change. | 19:58 |
| @fungicide:matrix.org | no need, that's close enough. sounds like it may just be new enough behavior that they didn't realize it | 19:58 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 890251: Fix linting errors https://review.opendev.org/c/zuul/zuul/+/890251 | 20:46 | |
| @jim:acmegating.com | fungi: ^ the solution to that, now that we're at 3.11+, is not disagreeable (it's how i would have written it at the time), so that's lucky. | 20:47 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 890252: Fix linting error https://review.opendev.org/c/zuul/nodepool/+/890252 | 20:49 | |
| @fungicide:matrix.org | cool, lgtm | 21:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!