| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 905848: Ignore soft dependencies when getting parent jobs https://review.opendev.org/c/zuul/zuul/+/905848 | 10:46 | |
| -@gerrit:opendev.org- Bernhard Berg proposed: [zuul/zuul] 905700: Add a zuul unreachable variable to indicate if a host node is unreachable https://review.opendev.org/c/zuul/zuul/+/905700 | 12:00 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 905848: Ignore soft dependencies when getting parent jobs https://review.opendev.org/c/zuul/zuul/+/905848 | 16:56 | |
| @fungicide:matrix.org | mild concern about the state of the `tox` abstract job in zuul-jobs (or `tox-siblings` role) which came up in a discussion in the #openstack-tc channel on oftc... i did not realize that adding depends-on to a change would automatically act as if the project that change is associated with getting effectively added to required-projects. `tox-siblings` uses that as a cue to install the project from source instead of the latest release on pypi, which would mean that a change in project "a" can depends-on a change in a dependency "b" and merge the change for "a" if the change for "b" merges even though without depends-on the job would test with the released version of "b" instead, deadlocking further runs for "a" until "b" gets a new release on pypi. is that really the case? | 19:36 |
|---|---|---|
| @fungicide:matrix.org | * mild concern about the state of the `tox` abstract job in zuul-jobs (or `tox-siblings` role) which came up in a discussion in the #openstack-tc channel on oftc... i did not realize that adding depends-on to a change would automatically act as if the project that change is associated with is effectively added to required-projects. `tox-siblings` uses that as a cue to install the project from source instead of the latest release on pypi, which would mean that a change in project "a" can depends-on a change in a dependency "b" and merge the change for "a" if the change for "b" merges even though without depends-on the job would test with the released version of "b" instead, deadlocking further runs for "a" until "b" gets a new release on pypi. is that really the case? | 19:37 |
| @jim:acmegating.com | fungi: it did not do that in this change: https://zuul.opendev.org/t/zuul/build/da00f7b1b5824197984ebb6711e88db5/log/zuul-info/inventory.yaml#144 | 19:49 |
| @jim:acmegating.com | fungi: so to be clear, i believe the answer to "is that really the case?" is "no". | 19:49 |
| @fungicide:matrix.org | thanks. Clark found an example where it seemed to: https://zuul.opendev.org/t/openstack/build/5eda057f8cb74be99534739252758610/log/zuul-info/inventory.yaml#241-250 | 19:50 |
| @clarkb:matrix.org | that one also sets required to false | 19:50 |
| @clarkb:matrix.org | but I didn't notice that initially. That said I don't think siblings handling checks that flag | 19:51 |
| @clarkb:matrix.org | and I'm not sure it should? | 19:51 |
| @jim:acmegating.com | ` projects: "{{ zuul.projects.values() | selectattr('required') | list }}"` | 19:51 |
| @jim:acmegating.com | from siblings ^ | 19:51 |
| @jim:acmegating.com | it does and should | 19:51 |
| @fungicide:matrix.org | yes, not doing so would create the deadlock loophole i was concerned about | 19:51 |
| @clarkb:matrix.org | corvus: aha I missed that because I wasl ooking in the python library code not the tasks | 19:52 |
| @fungicide:matrix.org | thanks corvus ! i am far less worried now ;) | 19:52 |
| @clarkb:matrix.org | the reason I'm not sure it should is that whether or not a project is required is insufficient info to avoid fungi's concern | 19:52 |
| @clarkb:matrix.org | you can require the project and install it from releases from pypi and then break in the same scenario | 19:52 |
| @fungicide:matrix.org | if a project is required then it will always be tested with the source branch state | 19:52 |
| @clarkb:matrix.org | it isn't actually adding any safe guards other than you have to do extra work to make depends on work with siblings. But maybe that is sufficient to avoid this problem in more situations | 19:53 |
| @jim:acmegating.com | yeah but that's a permanent job configuration/design issue, not a transient one from a casual depends-on | 19:53 |
| @fungicide:matrix.org | so consistency is maintained even after the depended-upon change merges | 19:53 |
| @clarkb:matrix.org | ok thats a good point. You can still trip but every job has the problem and it won't change | 19:53 |
| @jim:acmegating.com | (this sort of goes to why some repos have two jobs, some non-voting, etc) | 19:53 |
| @clarkb:matrix.org | s/every job/every build of the job/ | 19:54 |
| @clarkb:matrix.org | side note, I wonder if we should move logic like that into the library code. It will run faster too I think | 19:54 |
| @clarkb:matrix.org | > <@fungicide:matrix.org> if a project is required then it will always be tested with the source branch state | 19:55 |
| ya the issue would be specifically for a depends on, but I guess even then you'd have to depends on something from a different branch to break | ||
| @fungicide:matrix.org | 23.253.56.45 is the held keycloak node | 20:14 |
| @fungicide:matrix.org | i probably don't have more time to dig into it today (or tomorrow for that matter), but may be able to pick it back up again on friday assuming nothing catches fire in the meantime | 20:15 |
| @fungicide:matrix.org | er, wrong channel, sorry! | 20:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!