| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul] 826772: nodepool-zuul-functional: remove https://review.opendev.org/c/zuul/zuul/+/826772 | 00:19 | |
| -@gerrit:opendev.org- Ade Lee proposed: [zuul/zuul-jobs] 827366: WIP/DNM - Test new version of python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827366 | 04:03 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/nodepool] 827388: Dockerfile: explicitly install uidmap package https://review.opendev.org/c/zuul/nodepool/+/827388 | 04:05 | |
| -@gerrit:opendev.org- Ade Lee proposed: [zuul/zuul-jobs] 827366: WIP/DNM - Test new version of python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827366 | 04:49 | |
| -@gerrit:opendev.org- Ade Lee proposed: [zuul/zuul-jobs] 827366: WIP/DNM - Test new version of python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827366 | 05:15 | |
| -@gerrit:opendev.org- Ade Lee proposed: [zuul/zuul-jobs] 827366: WIP/DNM - Test new version of python3 https://review.opendev.org/c/zuul/zuul-jobs/+/827366 | 06:00 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/nodepool] 826773: nodepool-zuul-functional: remove https://review.opendev.org/c/zuul/nodepool/+/826773 | 07:34 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 827286: Fix version check when re-creating cached changes https://review.opendev.org/c/zuul/zuul/+/827286 | 12:16 | |
| @jsbronder:matrix.org | I'd like to run check and gate pipelines against every commit in a github pull request. Kinda the opposite of what was asked about here, http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-November/000616.html. Right now we do this with a bunch of custom groovy code in Jenkins which is suboptimal. Gitlab-runners are a bit better because they have dynamic child pipelines so I can generate a pipeline for each commit (https://docs.gitlab.com/ee/ci/pipelines/parent_child_pipelines.html#dynamic-child-pipelines) but that's still a bit jagged around the edges. Obviously I could just switch to Gerrit for review, but that's adding a hurdle I may not be able to get my org to jump over. So, is running the pipeline for each commit in a github pull request something that's supported by Zuul? | 14:53 |
|---|---|---|
| @jim:acmegating.com | jsbronder: no, PRs are the unit of review in github, so they're the unit of testing in zuul. if you're able to change development habits, you can limit a pr to one commit and use depends-on between prs to stack them | 14:56 |
| @jsbronder:matrix.org | That's what I expected, thanks for the confirmation. | 14:57 |
| @jsbronder:matrix.org | I wish I'd picked the right tools 5 years ago ;) | 14:57 |
| @jim:acmegating.com | (oh, and of course, within a single job, you could do something like bisect the commits if you wanted; zuul won't know anything about that and you probably thought of that already; just throwing it out there) | 14:58 |
| @fungicide:matrix.org | it's worth noting that there are code review systems where commits/patches are the unit of review, github just isn't one of them (it's arguably more of a social media platform than a code review system) | 15:01 |
| @jsbronder:matrix.org | corvus: Yeah, I think that ends up being similar to the shared library we have in Jenkins. If we're going to switch I'm hoping to use tools as they were designed to work rather then having to maintain our own somewhat extensive tooling inside. | 15:03 |
| @jsbronder:matrix.org | fungi: So I know about gerrit, are there others you'd suggest? | 15:03 |
| @fungicide:matrix.org | i believe phabricator is patch-based review as well | 15:04 |
| @fungicide:matrix.org | as far as ones zuul currently has a connection driver for | 15:05 |
| @jsbronder:matrix.org | We do require small, atomic commits, but the patch series itself is something that gives context to each commit and that we want to rebase/merge as a unit. | 15:06 |
| @jsbronder:matrix.org | Cool, I'll take a look. | 15:06 |
| @fungicide:matrix.org | * i believe pagure is patch-based review as well | 15:06 |
| @fungicide:matrix.org | sorry, corrected my message above, i meant pagure. i keep confusing the two | 15:06 |
| @fungicide:matrix.org | though on closer inspection, i'm wrong, it is based around a pull request workflow | 15:07 |
| @fungicide:matrix.org | so gerrit may be the only oatch-based workflow code review system zuul currently has a connection driver for | 15:07 |
| @fungicide:matrix.org | * so gerrit may be the only patch-based workflow code review system zuul currently has a connection driver for | 15:08 |
| @fungicide:matrix.org | not that it's all that involved to add new drivers | 15:08 |
| @fungicide:matrix.org | there's a bitbucket driver in the works, but it also looks like bb's code review model was copied from github's | 15:10 |
| @fungicide:matrix.org | so anyway, the other popular code review system i'm aware of which is patch-based (not counting things like the lkml) is phabricator, zuul just doesn't have a connection driver for it (not yet, at least) | 15:12 |
| @fungicide:matrix.org | but there are also a lot of proprietary code review systems i don't know much about | 15:15 |
| @fungicide:matrix.org | though speaking of the lkml, i wonder if a connection driver for their patchwork frontend might be feasible | 15:16 |
| @fungicide:matrix.org | i suppose the underlying api would essentially be smtp in that case anyway | 15:18 |
| @fungicide:matrix.org | jsbronder: also, you said you "know about" gerrit but i'm not sure how familiar you are with it. gerrit does have extensive support for "patch series" like you're describing, it just expects the individual patches to be reviewed and refined within the series rather than reviewing the series as a whole | 15:23 |
| @fungicide:matrix.org | so zuul's gerrit driver tests and reports on the individual patches in the series as well | 15:24 |
| @fungicide:matrix.org | though it obviously tests them in context, with the parents of each successive patch applied in the checkout | 15:25 |
| @jsbronder:matrix.org | fungi: So I'm not super familiar as a direct user but I'm pretty familiar using it to track various upstream projects. The workflow of submitting a patch series grouped by a 'topic' and reviewing/revising each commit (potentially adding/removing some) directly matches how we currently use github. | 15:34 |
| @jsbronder:matrix.org | We don't stack fixup commits or address comments in later commits; changes are rebased into commit that introduced the issue. | 15:35 |
| @jsbronder:matrix.org | * We don't stack fixup commits or address comments in later commits; changes are rebased into the commit that introduced the issue. | 15:35 |
| @fungicide:matrix.org | jsbronder: yeah, that's mostly how we use gerrit (fix up the commits within the series, not via follow-up commits). it's worth noting that "topics" aren't really the same thing. gerrit actually treats changes within a series (where one patch is the git parent of another) as an interrelationship | 15:56 |
| @fungicide:matrix.org | and zuul knows to respect those git relationships as implicit dependencies between changes | 15:57 |
| @fungicide:matrix.org | github users often think of this as a "rebase-oriented" workflow, but it's really only rebasing insofar as changes you make to a parent patch will inherently require rebasing the child patch to update the git parent ref | 15:58 |
| @fungicide:matrix.org | i'm trying to think of how zuul could logistically support that within a github pull request, but i think the primary challenges are that individual commits within a pr don't have a durable identifier like gerrit's change-id/index, and also the ui is oriented around checks reporting status for the pr not for the commits | 16:03 |
| @avass:vassast.org | Wow that was a very easy upgrade from 4.12 to 5.0 while at the same time we scaled up to 3 schedulers | 16:08 |
| @fungicide:matrix.org | durable identifiers are important in that zuul expects other commits (even commits targeting other repositories or in other code hosting systems intirely) to be able to declare them as implicit dependencies | 16:08 |
| @nborg:matrix.org | Sounds promising! Albin Vass | 16:08 |
| @fungicide:matrix.org | > <@avass:vassast.org> Wow that was a very easy upgrade from 4.12 to 5.0 while at the same time we scaled up to 3 schedulers | 16:08 |
| congrats! | ||
| @fungicide:matrix.org | we've been running 2 schedulers in opendev, and we definitely notice under load if we've taken one of them offline for an upgrade or something. the load distribution has been helping us a bunch | 16:09 |
| -@gerrit:opendev.org- Alfredo Moralejo proposed: [zuul/zuul-jobs] 827529: Make CentOS9 jobs voting https://review.opendev.org/c/zuul/zuul-jobs/+/827529 | 16:28 | |
| @fungicide:matrix.org | spamaps, mordred, and anyone else who might be a debian developer: in december i posted a proposal to the spi-general ml for debian to become an associate member organization of the openinfra foundation. lamby suggested we should hear feedback from debian developers involved in openinfra projects, so if you have time and want to post a response that would be awesome (note that their listmods aren't terribly active so if you're not subscribed your post may sit for weeks, though i can also prod them in irc if you give me a heads up). zigo and wendar replied, but more is better of course. the posts so far can be found in the list archive: http://lists.spi-inc.org/pipermail/spi-general/2021-December/ | 17:07 |
| @spamaps:spamaps.ems.host | > <@fungicide:matrix.org> spamaps, mordred, and anyone else who might be a debian developer: in december i posted a proposal to the spi-general ml for debian to become an associate member organization of the openinfra foundation. lamby suggested we should hear feedback from debian developers involved in openinfra projects, so if you have time and want to post a response that would be awesome (note that their listmods aren't terribly active so if you're not subscribed your post may sit for weeks, though i can also prod them in irc if you give me a heads up). zigo and wendar replied, but more is better of course. the posts so far can be found in the list archive: http://lists.spi-inc.org/pipermail/spi-general/2021-December/ | 17:16 |
| Oh interesting. I've been thinking of retiring from my DD creds.. I just don't keep up with things with my few tiny packages that never release. | ||
| @fungicide:matrix.org | no worries, i've also reached out to the starlingx community since their current push to revamp the project as a debian derivative distribution is being led by one or more dds as well | 17:18 |
| @fungicide:matrix.org | probably the only real zuul tie-ins for debian are that we use debian-based container images for our official releases, and that we have debian support in lots of our stdlib and do some platform testing on the debian nodes provided by opendev | 17:19 |
| @mordred:inaugust.com | fungi: yeah. although to be fair, we're not using debian for container base images as a direct conscious choice. we're using the python base images which in turn are built on debian. | 17:39 |
| @mordred:inaugust.com | same end result, obviously | 17:39 |
| @mordred:inaugust.com | we also tend to be fans :) | 17:39 |
| @fungicide:matrix.org | yeah, the base image distinction is a good point | 17:46 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 827540: Explicitly close finger sockets in web https://review.opendev.org/c/zuul/zuul/+/827540 | 18:19 | |
| @clarkb:matrix.org | corvus: is https://review.opendev.org/c/zuul/zuul/+/827286 the type of change we should make to all of the znode based records? I thought a number of them use the znode version comparison | 18:50 |
| @jim:acmegating.com | Clark: it's worth a check and keeping in mind for future things, but this specifically can happen because we can delete and the recreate the same znode | 18:58 |
| @jim:acmegating.com | (ie, if we delete change 1,2 from the cache, and then recreate it, it will have the same znode path) | 19:00 |
| @jim:acmegating.com | i'm not sure that holds for other uses of zstat.version; that's the thing to check | 19:00 |
| @clarkb:matrix.org | ya. I was thinking more high level like maybe we should just always use the monotonically increasing identifier to not have to think about when it is better | 19:01 |
| @jim:acmegating.com | i think that's probably not a bad idea... though... we may need to look into rollover :) | 19:01 |
| @clarkb:matrix.org | good point | 19:02 |
| @jim:acmegating.com | it's 64 bits though... | 19:02 |
| @clarkb:matrix.org | that is a really big number | 19:02 |
| @jim:acmegating.com | yeah, 64 bits should be enough for anybody ;) | 19:02 |
| @jim:acmegating.com | (it's actually 2x32 bit numbers, so it's a bit more complicated than that, but it's a lot of space regardless) | 19:03 |
| @jim:acmegating.com | the first is the epoch, which can change due to zk cluster operations, then the 2nd is the txid within the epoch | 19:04 |
| @jim:acmegating.com | opendev's zk cluster is on epoch 0x16 if i'm reading this right | 19:08 |
| @jim:acmegating.com | leader election increment the epoch | 19:08 |
| @clarkb:matrix.org | we're bumping it each time we upgrade then or when we need to do reboots | 19:09 |
| @fungicide:matrix.org | funny that matrix is interpreting ``0x16`` as ``0×16`` there | 19:14 |
| @fungicide:matrix.org | the former is hexadecimal notation, the latter is a mathematical expression equalling zero | 19:14 |
| @fungicide:matrix.org | that seems like slightly overzealous implicit markup | 19:15 |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/nodepool] 827388: Dockerfile: explicitly install uidmap package https://review.opendev.org/c/zuul/nodepool/+/827388 | 20:06 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 22:05 | |
| - [zuul/zuul] 827540: Explicitly close finger sockets in web https://review.opendev.org/c/zuul/zuul/+/827540 | ||
| - [zuul/zuul] 827564: Identify cherrypy requests in logs https://review.opendev.org/c/zuul/zuul/+/827564 | ||
| @jim:acmegating.com | i've wanted that last thing for so long... | 22:06 |
| @clarkb:matrix.org | corvus: I think the tests failed on the second change there due to the first one. Specifically it tries to unregister the streamer but then it complains that -1 is an invalid fd possibly because we've just closed the stream and it sets that value to -1 to indicate this? | 23:50 |
| @clarkb:matrix.org | corvus: maybe we need to unregister then close? | 23:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!