| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: | 09:35 | |
| - [zuul/zuul] 869862: Cleanup test logging https://review.opendev.org/c/zuul/zuul/+/869862 | ||
| - [zuul/zuul] 869870: Unvendor kazoo locks recipes https://review.opendev.org/c/zuul/zuul/+/869870 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 869865: Use unsafe_skip_rsa_key_validation with cryptography https://review.opendev.org/c/zuul/zuul/+/869865 | 09:35 | |
| @morucci:matrix.org | I'd like to kindly request a review on https://review.opendev.org/c/zuul/zuul/+/869559/ and its parent change. We are using the Gitlab driver since a while with gitlab.com however recently the Merge Request API changed a bit and makes the driver to be unreliable. We plan to land both changes in our production to remove our "production quick fix". | 13:51 |
|---|---|---|
| @morucci:matrix.org | The related issue is described here: https://gitlab.com/gitlab-org/gitlab/-/issues/386562 | 13:51 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/project-config] 843097: Increase check and gate pipeline priority https://review.opendev.org/c/zuul/project-config/+/843097 | 13:57 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 867251: Avoid unnecessary change dependency updates https://review.opendev.org/c/zuul/zuul/+/867251 | 16:10 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 869262: Further avoid unnecessary change dependency updates https://review.opendev.org/c/zuul/zuul/+/869262 | 16:10 | |
| @jpew:matrix.org | Clark: From reading the code, it doesn't look like `<project>.include-branches` affects what events Zuul processes at all; it only affects what branches it loads configuration items from :/ | 16:47 |
| @jpew:matrix.org | Maybe that is unintentional? | 16:49 |
| @jim:acmegating.com | it's intentional; there's no facility for telling zuul not to perform speculative merges for a particular branch of a project once that project has been added to a pipeline | 16:50 |
| @jpew:matrix.org | mmm, that's too bad. We really would like to get zuul running on an branch in a project without having it -1 changes on other branches because they have merge conflicts | 16:51 |
| @jkt_:matrix.org | I see that `zuul-jobs` has recently upgraded tox to v4. Do you guys know from the top of your head if tox v4 started skipping the installation of the package-under-test? | 17:06 |
| @jkt_:matrix.org | my test suite tries to execute a shell wrapper created via `[options.entry_points]`'s `console_scripts` which is no longer there | 17:08 |
| @jkt_:matrix.org | and I think I cannot really "pin" a previous version of zuul-jobs from within my `.zuul.yaml`, right? | 17:08 |
| @clarkb:matrix.org | > <@jkt_:matrix.org> I see that `zuul-jobs` has recently upgraded tox to v4. Do you guys know from the top of your head if tox v4 started skipping the installation of the package-under-test? | 17:11 |
| You probably have skipsdist set to true which prevents the install. You should drop that config item. | ||
| @clarkb:matrix.org | > <@jkt_:matrix.org> and I think I cannot really "pin" a previous version of zuul-jobs from within my `.zuul.yaml`, right? | 17:12 |
| We added a car to ensure-tox that allows you to set the tox version to '<4'. Pinning zuul-jobs back won't help because the old versions installed latest tox without a control for that | ||
| @jim:acmegating.com | Jan Kundrát: https://lists.zuul-ci.org/archives/list/zuul-announce@lists.zuul-ci.org/thread/3NNATSUTSIGP5FE2MDY5X2KJ5X4NB4PT/ | 17:15 |
| @michael_kelly_anet:matrix.org | bump https://review.opendev.org/c/zuul/zuul-jobs/+/869787 - any takers? I'm trying to use prepare-workspace-git with a repo that uses LFS and it's broken right from the get go :( | 17:29 |
| @jkt_:matrix.org | thanks! | 17:31 |
| -@gerrit:opendev.org- Michael Kelly proposed: | 17:35 | |
| - [zuul/zuul] 869784: manager: Fix TODO in executeJobs() https://review.opendev.org/c/zuul/zuul/+/869784 | ||
| - [zuul/zuul] 869785: manager: Remove unncessary job_graph check from executeJobs() https://review.opendev.org/c/zuul/zuul/+/869785 | ||
| - [zuul/zuul] 869786: model: Eliminate semaphore_handler parameter on findJobsTo*() https://review.opendev.org/c/zuul/zuul/+/869786 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of Fabien Boucher: [zuul/zuul] 869829: Fix scheduleFilesChanges fallback to target branch ref https://review.opendev.org/c/zuul/zuul/+/869829 | 18:14 | |
| @michael_kelly_anet:matrix.org | Any other takers? corvus ? | 18:20 |
| @michael_kelly_anet:matrix.org | Thanks for the feedback - you mentioned the 'base job test cycle' - what does one need to do to drive it through this? | 18:32 |
| @michael_kelly_anet:matrix.org | corvus: | 18:32 |
| @jim:acmegating.com | Michael Kelly: it's documented in the zuul-jobs repo. but i'd prefer the alternative i suggested and not changing that role. | 18:33 |
| @michael_kelly_anet:matrix.org | Hmm. So you're suggesting configuring the base job with this environment? If so, should this be documented somewhere (because this will always break with LFS repos where git-lfs is present?) | 18:34 |
| @jim:acmegating.com | Michael Kelly: yes (and also arguably, it breaking is not necessarily wrong) | 18:35 |
| @jim:acmegating.com | (masking the error may be a reasonable choice for you, but that may come as a surprise to others) | 18:36 |
| @michael_kelly_anet:matrix.org | I'm a bit confused on this one (sorry for belabouring the point, trying to understand the tradeoff here) - what's the benefit of not being able to even check out the repo? You can obviously configure around this, but why is that better than just being able to deal with LFS directly? Fwiw, I'm still thinking about how I'd actually *like* this to work as a user because I'm not entirely satisfied with my existing solution :) | 18:40 |
| @jim:acmegating.com | you're choosing to have an incomplete checkout as a solution to the problem. i don't think that should be the universal solution. | 18:42 |
| @michael_kelly_anet:matrix.org | Ah, I think maybe I explained this badly. | 18:42 |
| @michael_kelly_anet:matrix.org | There's two scenarios -> git-lfs binary is there or not | 18:44 |
| @michael_kelly_anet:matrix.org | If it's there, the job will fail 100% of the time because we set origin = /dev/null; | 18:45 |
| @michael_kelly_anet:matrix.org | (it's there == there in the base environment) | 18:45 |
| @michael_kelly_anet:matrix.org | If it's not there, we'll get an incomplete checkout instead | 18:46 |
| @michael_kelly_anet:matrix.org | tl;dr current scenario is either incomplete checkout or failed job | 18:46 |
| @michael_kelly_anet:matrix.org | My hack to get the *rest* of the checkout (which I don't currently really like and need to refine) is to have a separate lfs checkout role and pass the repo URL into that in a variable | 18:47 |
| @jim:acmegating.com | thanks for the clarification -- it does confirm that i understood correctly. i get that your solution is to have an incomplete checkout in all cases. i don't think that's an appropriate default for the role, and i also don't think that adding an option to switch that behavior is really worthwhile if you're able to do the same thing in a play env variable. | 18:49 |
| @michael_kelly_anet:matrix.org | Sure. I hear that - I'm wondering if, as I do this, (1) is this specific case documented somewhere? (2) should it be and if so where can I stick it? :) | 18:50 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 862522: Convert openstack driver to statemachine https://review.opendev.org/c/zuul/nodepool/+/862522 | 18:52 | |
| @michael_kelly_anet:matrix.org | Just trying to figure a good way to route someone to the prefered solution. | 18:53 |
| @jim:acmegating.com | Zuul itself draws the line at plain git. I'm not sure there's a universal solution that would be appropriate for everyone, but i think roles/jobs to support one or more solutions could be added to zuul-jobs. I think there's a place for howtos in the zuul docs. | 18:58 |
| @michael_kelly_anet:matrix.org | Sounds good. I'll try to rough something out in that respect. The other question w.r.t providing roles/jobs for the LFS part - one piece is the deducing where to grab the LFS objects from. Obviously, my current solution of just pushing the URL in a var can work, but my *ideal* solution would be one where this isn't necessary although I'm not sure that the current state exists to do this. What are your thoughts/preferences on this? | 19:02 |
| @jim:acmegating.com | i think getting the url and any necessary credentials is what makes that tricky; i can't see a route where we do it in zuul because we explicitly remove that information because it's dangerous. a zuul job should never interact with the upstream repo under normal circumstances. doing this to support lfs is very much an assertion that the user completely understands how zuul builds speculative git repos and is taking over responsibility for the correctness of those repos from zuul. so, i think passing that side-band is the way to go. | 19:07 |
| @michael_kelly_anet:matrix.org | Right. Ideally there'd be some sort of sideband passthrough for this so that it just magically looks like what you get when you git clone locally. | 19:08 |
| @michael_kelly_anet:matrix.org | Realistically, the way LFS works is a bit of a PITA this way. | 19:08 |
| @michael_kelly_anet:matrix.org | (fwiw, I hate LFS but for various reasons it's inescapable in my scenario) | 19:08 |
| @michael_kelly_anet:matrix.org | Hmm. Maybe a zuul-lfs repo would be useful as an intermediate box to stick pulled objects in. | 19:09 |
| @jim:acmegating.com | > <@michael_kelly_anet:matrix.org> (fwiw, I hate LFS but for various reasons it's inescapable in my scenario) | 19:09 |
| i've found that to be a fairly common sentiment :) | ||
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!