| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908211: Clean up safety check https://review.opendev.org/c/zuul/zuul/+/908211 | 00:56 | |
| -@gerrit:opendev.org- Szymon Datko proposed wip: [zuul/zuul-jobs] 908264: [DNM] Log from prepare-workspace https://review.opendev.org/c/zuul/zuul-jobs/+/908264 | 10:20 | |
| -@gerrit:opendev.org- Szymon Datko proposed wip: [zuul/zuul-jobs] 908264: [DNM] Log from prepare-workspace https://review.opendev.org/c/zuul/zuul-jobs/+/908264 | 10:21 | |
| -@gerrit:opendev.org- Szymon Datko marked as active: [zuul/zuul-jobs] 908264: [DNM] Log from prepare-workspace https://review.opendev.org/c/zuul/zuul-jobs/+/908264 | 10:35 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908211: Clean up safety check https://review.opendev.org/c/zuul/zuul/+/908211 | 14:44 | |
| @jkkadgar:matrix.org | Quick follow-up: I am still trying to trace down what is exactly happening but I believe the rebuilds occur in repositories with fail-fast enabled. When I did testing locally to reproduce I did not have it enabled and everything ran as expected but with it enabled it causes the dequeue. | 15:53 |
|---|---|---|
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 908202: Use exec in tutorial docker-compose files https://review.opendev.org/c/zuul/zuul/+/908202 | 15:59 | |
| @clarkb:matrix.org | I wonder if that means we don't check the retry flag properly when handling fail fast | 16:12 |
| @clarkb:matrix.org | fosdem ci cd devroom videos can be found here: https://video.fosdem.org/2024/ud2208/ figured this audience may have some interest in that | 17:07 |
| @jim:acmegating.com | zuul-maint: how does this look for a zuul release? commit 754e03d9e08f7117ede5c0e797faa24670d23d75 (HEAD -> master, tag: 9.3.1, origin/master, refs/changes/02/908202/1) | 17:13 |
| @clarkb:matrix.org | I think opendev is running 0e6b023a5f07f5842f3c7b17c1840a5b9cd22c3b on all services but executors. And is running 0e6b023a5f07f5842f3c7b17c1840a5b9cd22c3b on executors. The proposed commit is a quickstart change (which is self tested) that occurs just after the opendev executor version. I think that is fine and everything else should be reasonably well covered by opendev. We did add at least one feature since 9.3.0 though (Gerrit hashtag support). I don't think any of this is major enough to warrant a 9.4.0 if we prefer 9.3.1. | 17:18 |
| @jim:acmegating.com | good point; let's go ahead and do 9.4.0 | 17:19 |
| @jim:acmegating.com | zuul-maint: how about this instead for a zuul release: commit 754e03d9e08f7117ede5c0e797faa24670d23d75 (HEAD -> master, tag: 9.4.0, origin/master, refs/changes/02/908202/1) | 17:20 |
| @jim:acmegating.com | i believe zuul-client is ready for a release as well, but i think we should hold off on that until we approve the refactor change (just in case something changes, that way we don't have to immediately cut a .1 of zuul-client) | 17:23 |
| @jim:acmegating.com | i expect zuul 9.4.0 will serve as a rollback target in case something goes wrong with a 10.0 upgrade. i do think the refactor series starting at https://review.opendev.org/907506 is ready for final review and merging now. | 17:25 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908330: Remove most model_api backwards-compat handling https://review.opendev.org/c/zuul/zuul/+/908330 | 18:15 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908333: Remove updateJobParentData method https://review.opendev.org/c/zuul/zuul/+/908333 | 18:47 | |
| @jkkadgar:matrix.org | Follow-up part two: I got confused thinking fail-fast was the problem. It was not. This is what actually is occurring: Gate change A and Gate change B are building. Gate change A has a job that fails in pre-run and gets set to retry, however when the pre-run fails it also causes the post-run to fail, therefore the change gets marked as failed. Then change A retries the build job but change B dequeues all builds and starts over again because it sees that Gate change A had a build that failed. Do you consider this expected behavior? | 20:26 |
| @clarkb:matrix.org | jkkadgar: yes that would be expected | 20:29 |
| @clarkb:matrix.org | though I'm trying to remember why cleanup was different than post-run | 20:30 |
| @jkkadgar:matrix.org | So we should always make post-run robust enough to not be affected by pre-run? | 20:30 |
| @clarkb:matrix.org | that is the easy solution. There may be an argument that zuul should keep the retry pre-run failure state even if post run fails | 20:31 |
| @clarkb:matrix.org | we do want post-run to run though as that allows log collection to happen for debugging of the pre run failure | 20:31 |
| @clarkb:matrix.org | cleanup runs when jobs are cancelled. That is the difference | 20:33 |
| @jkkadgar:matrix.org | Ok, I would prefer for the pre-run failure state to keep even if post-run fails but I don't know if that would be a popular change. The reason is even when I robustify certain jobs, there is always potential that some other user who uses the system will not understand this little nuance. It also seems like it in general makes the system less fault tolerant. | 20:35 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908355: Deprecate Ansible 6 https://review.opendev.org/c/zuul/zuul/+/908355 | 21:22 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908360: Replace Ansible 6 with Ansible 9 https://review.opendev.org/c/zuul/zuul/+/908360 | 22:10 | |
| @jim:acmegating.com | If we follow our prior practice, we should actually release 9.5.0 with 908355. Then 908360 goes in 10.0.0. I'm fine with that, or we could just do everything in 10 if we don't think we need a release with the default switch. | 22:12 |
| @clarkb:matrix.org | corvus: 908355 lgtm and I think it should be ok to land that now. OpenDev should already be on ansible 8 everywhere by default | 22:57 |
| @clarkb:matrix.org | for 908360 I guess we would land that somewhat concurrently with the circular deps refactor? | 22:58 |
| @clarkb:matrix.org | so that both get tagged 10.0.0? | 22:59 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908366: Allow circular dependencies in the Zuul project https://review.opendev.org/c/zuul/zuul/+/908366 | 22:59 | |
| @jim:acmegating.com | yeah, assuming that we want 355 and 360 in separate releases, i think the plan would be: | 23:02 |
| #. Release 9.4.0 to have a rollback target with no db schema changes (done) | ||
| #. Merge the Ansible 6 deprecation | ||
| #. Release 9.5.0 | ||
| #. Merge the circular dependency refactor, the removal of Ansible 6, the addition of Ansible 9, and any other backwards-compat cleanups | ||
| #. Release 10.0.0 | ||
| @clarkb:matrix.org | I like that plan. I'll put the circular dep refactor and removal of ansible 6 reviews on my todo list for tomorrow morning | 23:03 |
| @jim:acmegating.com | kk, thx | 23:08 |
| @fungicide:matrix.org | :thumbs-up-emoji: | 23:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!