| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 913314: Limit bytes when reading Ansible output https://review.opendev.org/c/zuul/zuul/+/913314 | 08:43 | |
| @clarkb:matrix.org | corvus: re https://review.opendev.org/c/zuul/zuul/+/915188 what isn't clear to me is the artifact already exists and we're just annotating it with build info. I'm not sure if you want zuul to remove the artifact entirely if the change type isn't Change or just skip over adding extra info. If we only skip over adding the info then potentially the artifact could still be used later? Maybe that is fine (and would address the immediate problem | 15:21 |
|---|---|---|
| @jim:acmegating.com | Clark: remove entirely was my idea. like, the entire idea does not compute (which is why this went unnoticed). can probably move that check higher and skip the entire artifact check if changes aren't involved. | 15:42 |
| @clarkb:matrix.org | got it | 15:44 |
| -@gerrit:opendev.org- Clark Boylan proposed: [zuul/zuul] 915188: Handle artifacts created by non change refs https://review.opendev.org/c/zuul/zuul/+/915188 | 16:02 | |
| @clarkb:matrix.org | something like that maybe | 16:03 |
| @jkkadgar:matrix.org | Update on gerrit issue: when user creates a relation chain of patches A and B, then updates A and merges A, B is pointing to A1 instead of A2 patchest which is merged. When you attempt to gate B, nothing happens and Zuul provides no user input. I found that this is caused by getMissingNeededChanges checking needed_change.is_current_patchset and aborting or checking canMerge and finding that the older patchset didn't have the correct votes to merge. Ideally, the change should get enqueued to gate as there is nothing blocking it from gating. What is the correct way of handling this in the code (I am trying to make a change) | 20:49 |
| @clarkb:matrix.org | jkkadgar: in the general case `change should get enqueued to gate as there is nothing blocking it from gating` is not true. Gerrit will not let you merge a change whose parent is an old patchset. I guess the first thing to confirm is that in the case of cherry pick merges gerrit behaves differently. And then determine if you can detect this case separately from the default case | 21:06 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 915295: Add weekday support to older/newer-than https://review.opendev.org/c/zuul/zuul/+/915295 | 21:06 | |
| @jkkadgar:matrix.org | Gerrit cherry-pick does behave differently, you can merge a change whose parent is an old patcheset. I just don't know where/what to change to detect this. I was able to modify canMerge to check self.isMerged(change). It worked only if I voted, then unvoted, then revoted again to gate (this must cause some sort of refresh on the change to get past the current patchset abort) | 21:10 |
| @clarkb:matrix.org | ok when it comes to detecting the non default case I think the key is ensuring that we merged the parent and we're based on a "current" version of the parent. Zuul knows if it is applying cherry pick merge methods and could skip the current check in that case but then that opens you to potentially merging something that isn't valid (or attempting to, gerrit may still complain when it comes to submitting depending on the situation) | 21:12 |
| @clarkb:matrix.org | checking if the parent is the current patchset is the way that is done right now. Maybe there is a way to check if parent patchset was the one that was submitted (then ignore whether or not a subsequent patchset is created in the submit process) | 21:13 |
| @jkkadgar:matrix.org | Thanks, I am a little lost though, does the merger call cherry-pick before or after all the enqueuing happens? | 21:20 |
| @clarkb:matrix.org | "before". Zuul needs to merge/cherrpy pick things before it knows what to enqueue | 21:21 |
| @clarkb:matrix.org | it knows "I want to enqueue this change" one of the first steps it must take is merge in order to know what the config state is so that it can complete enquing | 21:22 |
| @jkkadgar:matrix.org | Ahh ok, so I really want to probably handle this in the cherryPick function in the merger | 21:23 |
| @jkkadgar:matrix.org | Thanks | 21:23 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 915300: Split build/buildset list queries into two https://review.opendev.org/c/zuul/zuul/+/915300 | 23:14 | |
| @jim:acmegating.com | Clark: fungi swest ^ that is everything we learned this weekend; i think that may provide good performance for all 3. | 23:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!