| @sjal:matrix.org | > <@clarkb:matrix.org> I doubt the issue is age. And more something that is a side effect of age like label updates/mergine/abandonment/etc | 10:22 |
|---|---|---|
| I've had some time today to check it and we've retroactively added another label to Gerrit. I was under an impression that if change is already merged then I can requeue it but Zuul works as intended by preventing gate without all required labels | ||
| @sjal:matrix.org | even if the change was able to successfully build before labels were added to the repository | 10:26 |
| @fungicide:matrix.org | sjal: out of curiosity, what's the point of continuing to run jobs for an old change which has already merged? to me, it sounds like a hacky workaround for something that could maybe be better supported with a separate pipeline/trigger instead | 14:18 |
| @sjal:matrix.org | > <@fungicide:matrix.org> sjal: out of curiosity, what's the point of continuing to run jobs for an old change which has already merged? to me, it sounds like a hacky workaround for something that could maybe be better supported with a separate pipeline/trigger instead | 14:21 |
| well, from my best knowledge you can't simply trigger existing merged changes other than from zuul-client and I can't make another commit. Perhaps creating a new pipeline for zuul-client-based triggers would be a good option here but how is it any better than requeuing gate and post | ||
| @sjal:matrix.org | what would be better approach? I'm doing this because some packages rotated already and they were apparently needed | 14:23 |
| @sjal:matrix.org | rotated in the external aritfact repository that is | 14:23 |
| @fungicide:matrix.org | is the change itself a necessary part of this for you, or merely an implementation detail? | 14:24 |
| @sjal:matrix.org | change itself is important because of how our release management procedure works | 14:24 |
| @fungicide:matrix.org | like, is there any reason the jobs can't run on the branch tip state instead of on an old change? | 14:24 |
| @sjal:matrix.org | yep:( | 14:24 |
| @sjal:matrix.org | well, otherwise it requires some legwork as well right? since you'd need to make an empty commit or something | 14:25 |
| @fungicide:matrix.org | no, zuul has the ability to run jobs on the current branch state instead of a specific change or commit or tag | 14:26 |
| @sjal:matrix.org | 'or something' as in trigger it, I'm triggering it via zuul-client I think I'm failing to see how's what you have in mind is superior | 14:26 |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 908794: Merger: add 'clone_filter' configuration setting https://review.opendev.org/c/zuul/zuul/+/908794 | 14:26 | |
| @fungicide:matrix.org | sjal: superior insofar as you're clearly doing post-merge testing but you're running pre-merge jobs which causes zuul to care about the validity of your merge requirements for the random change you've picked | 14:27 |
| @fungicide:matrix.org | zuul has triggers which are intended for post-merge testing and those don't care about your merge requirements (because the state that's being tested has already merged) | 14:28 |
| @fungicide:matrix.org | * sjal: superior insofar as you're clearly doing post-merge testing but you're running in a pre-merge pipeline which causes zuul to care about the validity of your merge requirements for the random change you've picked | 14:28 |
| @sjal:matrix.org | > <@fungicide:matrix.org> sjal: superior insofar as you're clearly doing post-merge testing but you're running in a pre-merge pipeline which causes zuul to care about the validity of your merge requirements for the random change you've picked | 14:34 |
| ok, yeah I understand now. By post-merge triggers do you mean any of the gerrit triggers? I don't think I like any of them for such a use case as I'd be afraid that users trigger it by an accident. Do you have any examples or something in mind? or how would you best recommend approach this | ||
| @mhuin:matrix.org | > <@gerrit:opendev.org> Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 908794: Merger: add 'clone_filter' configuration setting https://review.opendev.org/c/zuul/zuul/+/908794 | 14:34 |
| This is an experiment after attending "So you think you know Git" at FOSDEM'24. Partial cloning was demonstrated to be much faster for big repositories, see https://speakerdeck.com/schacon/so-you-think-you-know-git?slide=166 | ||
| @fungicide:matrix.org | sjal: you could, for example, set up a "periodic" pipeline with a timer trigger, and if you don't want it to run automatically very often just set it with a very infrequent timer. if zuul-client can't enqueue an item for a periodic pipeline, then that's probably a bug worth fixing. also if having the jobs run automatically is never an option, maybe it's worth considering adding a special syntax to the timer trigger to cause it to never run automatically, or adding a separate trigger similar to timer which just never runs automatically and requires manual enqueuing e.g. via zuul-client | 14:36 |
| @jim:acmegating.com | you can make a pipeline with no triggers | 14:40 |
| @fungicide:matrix.org | oh! even better, i didn't realize that was an option | 14:40 |
| @fungicide:matrix.org | though presumable zuul-client will need some extending to support enqueuing for that? | 14:41 |
| @jim:acmegating.com | mhu: is the idea to shift the burden of work from the clone step (which usually only happens once on a merger) to the fetch step? but then also that when fetching, if it doesn't need to fetch the ancient giant binary blob that someone checked in and then reverted out 2 years ago, it won't do that? so in summary: one-time merger clone is faster; first fetch is slower (until enough fetches warm the local repo?); but fetches and clones both avoid downloading "unecessary" blobs? | 14:43 |
| @mhuin:matrix.org | > <@jim:acmegating.com> mhu: is the idea to shift the burden of work from the clone step (which usually only happens once on a merger) to the fetch step? but then also that when fetching, if it doesn't need to fetch the ancient giant binary blob that someone checked in and then reverted out 2 years ago, it won't do that? so in summary: one-time merger clone is faster; first fetch is slower (until enough fetches warm the local repo?); but fetches and clones both avoid downloading "unecessary" blobs? | 14:47 |
| + | ||
| @jim:acmegating.com | Am i missing a bullseye emoji? or flying unicorn? ;) | 14:48 |
| @mhuin:matrix.org | > <@jim:acmegating.com> Am i missing a bullseye emoji? or flying unicorn? ;) | 14:49 |
| Nah, you've just witnessed a big clumsy hand hitting Return too fast | ||
| @mhuin:matrix.org | > <@jim:acmegating.com> mhu: is the idea to shift the burden of work from the clone step (which usually only happens once on a merger) to the fetch step? but then also that when fetching, if it doesn't need to fetch the ancient giant binary blob that someone checked in and then reverted out 2 years ago, it won't do that? so in summary: one-time merger clone is faster; first fetch is slower (until enough fetches warm the local repo?); but fetches and clones both avoid downloading "unecessary" blobs? | 14:51 |
| * If I understand the feature correctly, that's what I think would occur, yes. There are more details about this here https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ with pretty pictures that illustrate what happens. | ||
| @mhuin:matrix.org | This seems to be however mostly useful for large repos - the cutoff in terms of file and history size being unclear | 14:53 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908797: Fix filtering on status page https://review.opendev.org/c/zuul/zuul/+/908797 | 14:53 | |
| @mhuin:matrix.org | furthermore, while Scott Charon's presentation boasts impressive cloning times with the linux repo (from 24 minutes for a full clone to 2 minutes for a treeless clone), other tests suggest the speed boost comes with larger CPU costs (see https://github.blog/2020-12-22-git-clone-a-data-driven-study-on-cloning-behaviors/ ) | 14:56 |
| @jim:acmegating.com | mhu: other than what you've identified, i think my main additional concerns would be (1) verifying that subsequent fetches do download any blobs/etc needed for a full checkout or merge -- because by the time we hand over a repo to a job, it needs to be self-sufficient (can't fetch from origin any more). and (2) if this does prove to be useful, this probably needs to be a per-project tenant config setting (but that's more plumbing, so that's just something to keep in mind for when it's less experimental) | 14:57 |
| @mhuin:matrix.org | re. 1 if a job requires to perform a git diff or git blame or resetting to a previous commit then yeah, treeless/blobless clones aren't suitable - but then I'm not sure any job would do that; or that could be documented ("if you intend to do this, do not use partial cloning optimizations") | 15:07 |
| @mhuin:matrix.org | re 2. yeah that'd be ideal since this is so tied to repos' specifics | 15:07 |
| @fungicide:matrix.org | in opendev we definitely have jobs that rely on git diff to identify what's being changed (though that would generally be between HEAD and origin/HEAD or, more naively, between HEAD and HEAD^1) | 15:10 |
| @fungicide:matrix.org | actually, release note jobs with reno may need deeper inspection of more of the history, since they need to extract specific files added in specific commits between each tag | 15:12 |
| @fungicide:matrix.org | and we have jobs that rely on git notes refs too, if that would be impacted at all | 15:13 |
| @jim:acmegating.com | lol there's a flaky unit test that's hitting like every change we run jobs on, but the one change i want it to hit, https://review.opendev.org/908510 has never seen it | 15:14 |
| @fungicide:matrix.org | heisenbug? | 15:15 |
| @jim:acmegating.com | (if it continues, that actually does provide data; it's suggestive of a very tight timing issue and the solution might just be to bump some timeouts) | 15:15 |
| @mhuin:matrix.org | > <@fungicide:matrix.org> and we have jobs that rely on git notes refs too, if that would be impacted at all | 15:16 |
| depends on where the git note refs are stored, if it's in blobs then you can't do blobless/treeless clone | ||
| @fungicide:matrix.org | mhu: well, storage aside, notes are tied to commits, so without distinct commits they may not have the necessary data for that association | 15:18 |
| @fungicide:matrix.org | but they're tied to the commit refs, so may not actually need the blobs | 15:19 |
| @fungicide:matrix.org | i'd need to experiment | 15:19 |
| @mhuin:matrix.org | basically: it's complicated, your mileage may vary, here be dragons | 15:20 |
| @fungicide:matrix.org | notes have to be fetched independently of refs anyway | 15:20 |
| @fungicide:matrix.org | the automatic way to get them is by extending the fetch pattern in git config | 15:20 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908834: Increase timeouts in TestComponentRegistry https://review.opendev.org/c/zuul/zuul/+/908834 | 15:53 | |
| @clarkb:matrix.org | fungi: all of openstack and zuul also rely on complete git history for versioning | 16:23 |
| @fungicide:matrix.org | oh, right, pbr wants it, just unclear if it would be sufficient to have blobless refs to generate that info | 16:24 |
| @clarkb:matrix.org | fungi: it may be, but mhu's change also lets you set clone depth | 16:25 |
| @clarkb:matrix.org | and that will definitely create problems | 16:25 |
| @clarkb:matrix.org | I don't necessarily think it is a bad feature, but I think we need to better undersatnd how it will impact repos in jobs (and left a review to that effect) | 16:26 |
| @jim:acmegating.com | blobless sounds like it may be more likely to be generally useful with fewer problems. | 16:26 |
| @clarkb:matrix.org | corvus: both circular dep web ui fixups lgtm | 16:29 |
| @clarkb:matrix.org | corvus: also the updated https://review.opendev.org/c/zuul/nodepool/+/908613 to fix nodepool dib build testing of centos would be helpful | 16:36 |
| @jim:acmegating.com | Clark: lgtm. | 16:38 |
| @jim:acmegating.com | https://review.opendev.org/908670 and https://review.opendev.org/908834 are both to address test races; reviews of those may help get those fixes in faster :) | 16:41 |
| @clarkb:matrix.org | ack I'll look at those next | 16:42 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 908366: Allow circular dependencies in the Zuul project https://review.opendev.org/c/zuul/zuul/+/908366 | 16:47 | |
| @clarkb:matrix.org | both of the unittest fixes lgtm as well. They seem straightforward enough (and only touch testing) so we may just want to approve them now? | 16:48 |
| @jim:acmegating.com | yeah; 834 is a little bit of a shot in the dark but shouldn't hurt | 16:48 |
| @jim:acmegating.com | the webui regression fixes are also straightforward and follow existing patterns so i'm inclined to approve them if another review doesn't show up shortly. | 16:50 |
| @fungicide:matrix.org | the site preview for https://zuul.opendev.org/t/zuul/build/1c05f5ce816748f09fda22aa843e109b performs a surprising redirect. not sure how it even continues to work after that, but somehow it does? maybe an odd firefox behavior, i haven't tried in other browsers | 16:58 |
| @jim:acmegating.com | fungi: it's all an illusion (not a real redirect) | 16:59 |
| @jim:acmegating.com | just js rewriting the url | 17:00 |
| @clarkb:matrix.org | everything is alraedy loaded into your browser at that point and then its just operating on the links/paths you give it right? | 17:00 |
| @jim:acmegating.com | yep | 17:00 |
| @fungicide:matrix.org | got it, that explains the behavior | 17:00 |
| @fungicide:matrix.org | anyway, looking at the openstack tenant status through that and then filtering by 904260 should currently turn up one item in the gate pipeline, but returns two (one of which is a separate change). is that expected? | 17:01 |
| @clarkb:matrix.org | I think 904260 may show up in the other change's chagne list? | 17:03 |
| @clarkb:matrix.org | I don't see why yet but that could explain why it shows up | 17:03 |
| @jim:acmegating.com | i'll see if i can come up with an explanation before it changes :) | 17:04 |
| @fungicide:matrix.org | well, if i filter for 899868 i get all the changes ahead of it in the gate too, so seems like it doesn't filter out changes sharing the same queue maybe? | 17:05 |
| @fungicide:matrix.org | that seems to be the common factor anyway | 17:05 |
| @fungicide:matrix.org | i don't use the status view filter very often, so not sure if that's how it always worked | 17:06 |
| @clarkb:matrix.org | The update to the filter is looking at each ref in the items (because items can have more than one ref now). And ya maybe shared queues in dependent pipelines have refs set up like that for items | 17:06 |
| @jim:acmegating.com | i'm also unfamiliar with the filter, but it looks like it's not so much a "change/item" filter as a "queue" filter. so apparently it will always show you the entire queue with any matching change/item | 17:07 |
| @clarkb:matrix.org | oh ya the functions is named "filterQueue" | 17:09 |
| @jim:acmegating.com | so yeah, in this particular case it's finding one match, but that match is in a queue with two items | 17:11 |
| @fungicide:matrix.org | okay, so it's working as designed, also presumably as intended | 17:11 |
| @jim:acmegating.com | i guess the idea is probably ppl still want to see what's ahead of their changes of interest in the gate | 17:11 |
| @fungicide:matrix.org | wfm. thanks! | 17:12 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908845: DNM: test circular dep https://review.opendev.org/c/zuul/zuul/+/908845 | 17:32 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 908846: DNM: test circular dep https://review.opendev.org/c/zuul/nodepool/+/908846 | 17:33 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908845: DNM: test circular dep https://review.opendev.org/c/zuul/zuul/+/908845 | 17:34 | |
| @jim:acmegating.com | there's a circular dep. an interesting thing is that we don't get dedup on the quick-start job because the job graph isn't the same in the two repos (we don't run the standalone registry job in the zuul repo) | 17:35 |
| @jim:acmegating.com | oh and the image build jobs are different | 17:37 |
| @clarkb:matrix.org | the non monospace font for the change numbers bothers me for some reason | 17:37 |
| @jim:acmegating.com | yeah me too | 17:37 |
| @clarkb:matrix.org | on the status page I mean | 17:37 |
| -@gerrit:opendev.org- Zuul merged on behalf of Clark Boylan: [zuul/nodepool] 908613: Fetch compatibile dnf download command in container image https://review.opendev.org/c/zuul/nodepool/+/908613 | 18:13 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 908670: Fix race in test_deps_by_topic_git_needs https://review.opendev.org/c/zuul/zuul/+/908670 | 18:13 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908853: Fix subway graph line gap https://review.opendev.org/c/zuul/zuul/+/908853 | 18:14 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 18:18 | |
| - [zuul/zuul] 906203: Add dark mode images for status page https://review.opendev.org/c/zuul/zuul/+/906203 | ||
| - [zuul/zuul] 908853: Fix subway graph line gap https://review.opendev.org/c/zuul/zuul/+/908853 | ||
| - [zuul/zuul] 906204: Wrap long job names on status page https://review.opendev.org/c/zuul/zuul/+/906204 | ||
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 908747: Fix re-enqueue buildset in web ui https://review.opendev.org/c/zuul/zuul/+/908747 | 18:20 | |
| @fungicide:matrix.org | corvus: regarding the note at https://zuul-ci.org/docs/zuul/latest/howtos/openid-with-keycloak.html#configuring-jwt-signing-algorithms a bit of digging suggests that was fixed in pyjwt 2.5.0 and may no longer be a necessary step? also latest keycloak makes disabling that harder (i think it involves deleting the rsa-enc-generated provider now, as it no longer presents an option to disable listed keys) | 18:23 |
| @fungicide:matrix.org | changelog entry includes "Skip keys with incompatible alg when loading JWKSet by @DaGuich in https://github.com/jpadilla/pyjwt/pull/762" | 18:24 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [zuul/zuul] 908855: Refresh Keycloak OpenID Howto for latest Keycloak https://review.opendev.org/c/zuul/zuul/+/908855 | 18:48 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/nodepool] 904220: Fix max concurrency log line https://review.opendev.org/c/zuul/nodepool/+/904220 | 19:51 | |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [zuul/zuul] 908855: Refresh Keycloak OpenID Howto for latest Keycloak https://review.opendev.org/c/zuul/zuul/+/908855 | 20:26 | |
| @jim:acmegating.com | fungi: cool! | 20:32 |
| @jim:acmegating.com | hopefully the tutorial testing will be helpful there | 20:32 |
| @fungicide:matrix.org | yes, that's my hope as well (and why i adjusted the realm blob) | 20:44 |
| @fungicide:matrix.org | unfortunately, if true, it means that note was no longer accurate about 2 months after it got added, and we've had it in there for something like 1.5 years | 20:45 |
| @clarkb:matrix.org | corvus: that increase of the timeouts change really doesn't want to merge | 21:04 |
| @clarkb:matrix.org | the fix for status page filtering is still testing though so thats good | 21:05 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 908797: Fix filtering on status page https://review.opendev.org/c/zuul/zuul/+/908797 | 21:11 | |
| @fungicide:matrix.org | and there it goes! | 21:11 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 908865: Fix test_timer_preserve_jobs race https://review.opendev.org/c/zuul/zuul/+/908865 | 21:13 | |
| @jim:acmegating.com | Clark: ^ but that came out of it, so... :) | 21:13 |
| @jim:acmegating.com | these changes are also bugfix-level changes for the status page: https://review.opendev.org/906203 https://review.opendev.org/908853https://review.opendev.org/906204 but not regressions from the recent updates | 21:15 |
| @clarkb:matrix.org | ack I'll look at reviewing those momentarily. | 21:18 |
| @jim:acmegating.com | * these changes are also bugfix-level changes for the status page: https://review.opendev.org/906203 https://review.opendev.org/908853 https://review.opendev.org/906204 but not regressions from the recent updates | 21:18 |
| @jim:acmegating.com | i took advantage of all the gate resets earlier to do the subway lines fix | 21:19 |
| @fungicide:matrix.org | corvus: speaking of subway graph rendering bugs, not sure if it's known, but in dark mode the curved line tile ends up rendering with the light bg/fg instead of dark | 21:22 |
| @jim:acmegating.com | fungi: that's one of the above fixes | 21:22 |
| @fungicide:matrix.org | oh, i missed that there was a third one! | 21:23 |
| @fungicide:matrix.org | yep, exactly that change. perfect | 21:23 |
| @fungicide:matrix.org | usually i rely on openstack as a source of failing gate pipeline changes to preview such ui fixes, but it's uncharacteristically quiet there at the moment | 21:31 |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [zuul/zuul] 908855: Refresh Keycloak OpenID Howto for latest Keycloak https://review.opendev.org/c/zuul/zuul/+/908855 | 22:26 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 908834: Increase timeouts in TestComponentRegistry https://review.opendev.org/c/zuul/zuul/+/908834 | 23:34 | |
| -@gerrit:opendev.org- Jeremy Stanley https://matrix.to/#/@fungicide:matrix.org proposed: [zuul/zuul] 908869: Test with Keycloak 23 https://review.opendev.org/c/zuul/zuul/+/908869 | 23:51 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!