| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 914928: Fix deletion of intermediate image builds https://review.opendev.org/c/zuul/nodepool/+/914928 | 06:34 | |
| @fserucas:matrix.org | Hi, | 08:57 |
|---|---|---|
| Could you please review this change https://review.opendev.org/c/zuul/zuul/+/908507. | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 914947: Temporarily pin urllib3 before 2.1.0 https://review.opendev.org/c/zuul/zuul/+/914947 | 09:53 | |
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/zuul] 914949: Zuul-web: Fix literal filter queries being esacped https://review.opendev.org/c/zuul/zuul/+/914949 | 10:19 | |
| -@gerrit:opendev.org- Francisco Seruca Salgado proposed: [zuul/zuul] 908507: Update decrypt_secret.py script https://review.opendev.org/c/zuul/zuul/+/908507 | 12:41 | |
| @jpew:matrix.org | Would someone mind a look at https://review.opendev.org/c/zuul/zuul/+/914818?forceReload=true ? We've had users complain that changes regate when they make any comment on a failed change | 14:09 |
| @jkkadgar:matrix.org | Question when merge-mode: cherry-pick is set: When a user creates a gerrit relation chain change of A and B and then gates and merges A, B now will not regate until the patch is rebased or a new patch is submitted. Applying the gerrit vote for it to gate will cause nothing to happen (no comments or jobs will run). Does anyone know why this is happening? | 14:15 |
| @clarkb:matrix.org | I think that is due to cherry pick creating a new commit on merge which effectively unparents the child and parent change. This is why you need to rebase. I would look at the Gerrit merge ability state of the child to confirm. | 14:18 |
| @jkkadgar:matrix.org | Is it possible to change the gerrit driver to handle this case and still gate? | 14:19 |
| @clarkb:matrix.org | Currently zuul relies on Gerrit to specify whether or not a change is mergeable. I don't know if zuul can infer the same state on a more accurate way than Gerrit | 14:20 |
| @clarkb:matrix.org | Because even if zuul ran the tests Gerrit would still refuse to merge the change | 14:21 |
| @clarkb:matrix.org | It's possible that if zuul were updated to do the merging instead of Gerrit then zuul could do a more semantically meaningful cherry pick that doesn't break the relationship chains | 14:21 |
| @jkkadgar:matrix.org | Hmm, ok thanks | 14:24 |
| @clarkb:matrix.org | But you should confirm that Gerrit says B cannot merge after A mergea | 14:25 |
| @jkkadgar:matrix.org | Well B can merge according to gerrit and will merge if you submit it, it's just Zuul doesn't know | 14:26 |
| @jkkadgar:matrix.org | Until you rebase or submit a new patch | 14:28 |
| @clarkb:matrix.org | Zuul should say why it is ignoring a change if you recheck it or similar. Grep the logs for the event id associated with that comment event and trace that through the scheduler | 14:30 |
| @harbott.osism.tech:regio.chat | iiuc if B is based on A, but A doesn't get merged but rather A2, the cherry-pick of A onto HEAD, then gerrit will consider B unmergeable until a rebase. not sure zuul can do much about that. IMO merge-mode: cherry-pick is not compatible with stacking changes in gerrit, you should not combine that | 15:30 |
| @fungicide:matrix.org | pretty much all gerrit merge modes other than merge-if-necessary are broken in subtle (or not-so-subtle in the ff-only case) ways | 15:33 |
| @fungicide:matrix.org | they may work in small-scale teams without interdependencies or when someone is making sure every change is sequenced prior to approval (and assuming none fail gating), but quickly fall apart in more complicated scenarios | 15:34 |
| @fungicide:matrix.org | er, i guess gerrit calls them "submit strategies" | 15:36 |
| @fungicide:matrix.org | also merge-always is probably fine, merge-if-necessary is just an optimization to result in fewer merge commits when they're not needed | 15:37 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 914990: Restore mysql index hint https://review.opendev.org/c/zuul/zuul/+/914990 | 17:26 | |
| @vlotorev:matrix.org | Hi, since zuul 9.5.0 jobs with both dependencies and provides/requires stopped running in supercedent pipeline. | 18:09 |
| I reproduced this issue on zuul.opendev.org - https://zuul.opendev.org/t/openstack/status , there you can find jobs for periodic and post pipelines for 'opendev/sandbox' repo, one of jobs is in "queued" state for > 16 hours. | ||
| The same jobs were run in check pipeline without errors. | ||
| @clarkb:matrix.org | vlotorev: yes we saw. Unfortunately there are a number of other fires we've been dealing with all week | 18:10 |
| @clarkb:matrix.org | I don't know if/when I'll haev time to look at that right now | 18:11 |
| @clarkb:matrix.org | But also no one should feel compelled to wait for me | 18:12 |
| @clarkb:matrix.org | side note: a potentially more helpful reproduction would be in zuul's test framework | 18:13 |
| @clarkb:matrix.org | then anyone interested in zuul can see the errors in the logs instead of just those with opendev lgo access | 18:13 |
| @vlotorev:matrix.org | Clark: for feedback. | 18:13 |
| I'm just wondering if you consider this as regression that might be fixed in future or should I drop using dependencies and provides/requires in one buildset (that would be highly undesirable). | ||
| @clarkb:matrix.org | its too early for me to say. I haven't had a chance to reason about wht it is happening. It being broken in 9.5.0 implies this wasn't related to the circular deps refactoring unless it happened very early in that process | 18:15 |
| @clarkb:matrix.org | looking at the traceback I suspect it is fixable | 18:16 |
| @clarkb:matrix.org | we're just looking for the wrong attributes on the wrong event type related items | 18:16 |
| @vlotorev:matrix.org | * Clark: thanks for feedback. | 18:20 |
| I'm just wondering if you consider this as regression that might be fixed in future or should I drop using dependencies and provides/requires in one buildset (that would be highly undesirable). | ||
| @clarkb:matrix.org | But thinking out loud here: provides/requires are for dependencies between buildsets. Supercedent pipelines ensure that only one buildset is ever active at a time. It may end up that the fix is to avoid the crash, but may noop anyway? | 18:21 |
| @clarkb:matrix.org | basically it will look for provides and not find any because no other buildset is active? I can't remember what the lifetime validity of a provides is off the top of my head | 18:22 |
| @vlotorev:matrix.org | job.dependencies makes jobs run in specific order but doesn't pass zuul.artifacts from first jobs to later. | 18:37 |
| I started using provides just to pass zuul.artifacts. | ||
| @vlotorev:matrix.org | * job.dependencies makes jobs run in specific order but doesn't pass zuul.artifacts from first jobs to the later. | 18:38 |
| I started using provides just to pass zuul.artifacts. | ||
| @clarkb:matrix.org | Yes, but I think that's mostly for speculative state? At some point you're expected to have a proper artifact outside of zuul? But I may be confusing myself due to how we do docker image builds and promotions | 18:42 |
| @jim:acmegating.com | dependencies should pass artifacts | 19:22 |
| @jim:acmegating.com | perhaps the confusion is that the docs explicitly mention that for provides/requires, but not dependencies. i think a doc update to clarify that would be good. | 19:23 |
| @jim:acmegating.com | provides/requires should have no effect within a single buildset | 19:24 |
| @jim:acmegating.com | that one is in the docs, but it's subtle: `...by other jobs for other changes...` with the `for other changes` part meaning other buildsets, effectively. that could probably use more words. :) | 19:26 |
| @jim:acmegating.com | (but https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.requires does have some more words that explains it a bit more) | 19:26 |
| @jim:acmegating.com | i agree the traceback is a problem and should be corrected -- but the correction will result in it not doing anything, so if it's convenient to remove provides/requires there, that would be a quick fix. it probably slipped through testing because that construction isn't useful -- except of course it's useful to be able to have those attributes on a job and have them used in check but ignored in post. | 19:28 |
| @jim:acmegating.com | supercedent pipelines are kind of a weird place to use them -- in that zuul might actually try to do something, but i would be really surprised if the thing it does is the thing that a user would actually desire. | 19:30 |
| @jim:acmegating.com | (because supercedent pipelines do have a queue, so it's possible for it to match a provides to a requires, but given that the intention with supercedent is to skip changes, i'm not sure the behavior in that case would be very reliable) | 19:31 |
| -@gerrit:opendev.org- Mohammed Naser proposed: [zuul/zuul] 915024: fix(web): stop toggling builds on clicks https://review.opendev.org/c/zuul/zuul/+/915024 | 20:14 | |
| -@gerrit:opendev.org- Mohammed Naser proposed: [zuul/zuul-jobs] 915025: chore: refactor setting buildset_registry fact https://review.opendev.org/c/zuul/zuul-jobs/+/915025 | 20:57 | |
| -@gerrit:opendev.org- Mohammed Naser proposed: [zuul/zuul-jobs] 915025: chore: refactor setting buildset_registry fact https://review.opendev.org/c/zuul/zuul-jobs/+/915025 | 22:47 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!