| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 831323: configure-mirrors: fix stripped newline https://review.opendev.org/c/zuul/zuul-jobs/+/831323 | 00:04 | |
| @iwienand:matrix.org | Clark: ahh, good thought. i bet also it's not the distro as such update, but that the repos have different podman versions for focal v bionic | 00:05 |
|---|---|---|
| @iwienand:matrix.org | sorry, distracted by ^^ which i hope passes but we want to get in, because it looks like we've got borked apt configs | 00:06 |
| @jim:acmegating.com | > <@clarkb:matrix.org> ianw: corvus is it possible one of the earlier test playbooks is leaking the localhost:9000 pushed file to the registry into when that playbook runs? Then when you check the listing it still shows as localhost:9000 because the sha matches what was in docker so the pull is a noop? | 00:07 |
| No, you can have multiple image tags pointing to the same image. If that test is failing it means podman isn't pulling the image we requested. | ||
| @iwienand:matrix.org | that is the case, bionic is install 3.0.1-2 and focal 3.4.something | 00:08 |
| @jim:acmegating.com | Maybe something about podman not assuming docker.io. | 00:09 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 831323: configure-mirrors: fix stripped newline https://review.opendev.org/c/zuul/zuul-jobs/+/831323 | 00:10 | |
| @y2kenny:matrix.org | are there any way to help debug zuul-web authorization issue? I tried adding -d to launching zuul-web but that don't seem to add any more info. I can see the http 401 but I have no idea which admin rule failed. | 00:16 |
| @y2kenny:matrix.org | or how the rule failed... I actually only set the iss condition | 00:18 |
| @y2kenny:matrix.org | are there other ways to do enqueue/dequeue beside web auth? I guess with 5.0.0 web auth is the only way left? | 00:28 |
| @clarkb:matrix.org | Kenny Ho: yes, with 5.0 there is no gearman anymroe so need to rely on webauth | 00:29 |
| @clarkb:matrix.org | I'm not sure if the logging can be set up to be more verbose on the web side | 00:29 |
| @y2kenny:matrix.org | sigh... ok... I am out of idea | 00:29 |
| @y2kenny:matrix.org | I have setup dex to bridge oidc with my corp ldap and able to authenticate but not able to authorize | 00:30 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 831326: ensure-podman: add containernetworking-plugins https://review.opendev.org/c/zuul/zuul-jobs/+/831326 | 00:30 | |
| @clarkb:matrix.org | Kenny Ho: maybe set up a local token and ensure that works then build up from there | 00:30 |
| @clarkb:matrix.org | that removes a lot of moving parts | 00:30 |
| @iwienand:matrix.org | ^^ that should remove all the extra fluff warnings we're getting with the focal ugprade anyway | 00:31 |
| -@gerrit:opendev.org- Ian Wienand proposed: | 00:31 | |
| - [zuul/zuul-registry] 831135: Update testing to Ubuntu Focal https://review.opendev.org/c/zuul/zuul-registry/+/831135 | ||
| - [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | ||
| @y2kenny:matrix.org | Clark: How do I setup local token? Is it via allow_authz_override? | 00:32 |
| @clarkb:matrix.org | Kenny Ho: https://opendev.org/openstack/project-config/src/branch/master/zuul/main.yaml#L1-L4 that is how we do it. We set the issuer to zuul itself and then set it up in our zuul config thatway | 00:33 |
| @y2kenny:matrix.org | ooo... I was wondering about that... because my iss is my dex server and I wasn't sure how the opendev example works. | 00:35 |
| @clarkb:matrix.org | Kenny Ho: https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/zuul/templates/zuul.conf.j2#L57-L70 that is what the zuul config looks like | 00:36 |
| @y2kenny:matrix.org | ah yes... I was just about to ask that. | 00:37 |
| @y2kenny:matrix.org | ok... I will give that a try. Thanks! | 00:37 |
| @y2kenny:matrix.org | and the zuul_local_auth_secret is the auth-token used by zuul-client? | 00:38 |
| @clarkb:matrix.org | Kenny Ho: you'll need to manually provision the token once you've done this. It isn't automated via oidc | 00:39 |
| @clarkb:matrix.org | Kenny Ho: no thats the secret used to generate tokens. There is a zuul-client (or is it zuul?) command to generate an HS256 token | 00:39 |
| @y2kenny:matrix.org | ah ok. | 00:39 |
| @y2kenny:matrix.org | instead of generating the token via web login | 00:39 |
| @clarkb:matrix.org | Kenny Ho: yup https://zuul-ci.org/docs/zuul/latest/client.html#create-auth-token it is a zuul command | 00:40 |
| @y2kenny:matrix.org | Clark: yay it worked! Thanks! One thing I noticed though... for zuul-client enqueue --change is required (which needs change#,patch# for gerrit) but I think --ref should be allowed also? | 01:08 |
| @clarkb:matrix.org | Is there an enqueue-ref command with zuul-client? It was split with the gearman tools | 01:25 |
| @y2kenny:matrix.org | Oh | 01:25 |
| @y2kenny:matrix.org | there may be | 01:25 |
| @y2kenny:matrix.org | I think I came across that before but it escape my mind... sorry about that | 01:26 |
| -@gerrit:opendev.org- Ian Wienand proposed: | 01:26 | |
| - [zuul/zuul-registry] 831135: Update testing to Ubuntu Focal https://review.opendev.org/c/zuul/zuul-registry/+/831135 | ||
| - [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | ||
| @jpew:matrix.org | When I have a single gerrit gating in Zuul, it works just fine. When Zuul starts stacking gerrits, it will merge the top one, but then thinks it fails and requeues all the subsequent ones which causes a lot of rebuilds. Does anyone know why this is? | 01:38 |
| @jpew:matrix.org | e.g. the top change in the gate queue cherry-picks successfully, but Zuul thinks it fails for some reason | 01:38 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-jobs] 831326: ensure-podman: add containernetworking-plugins https://review.opendev.org/c/zuul/zuul-jobs/+/831326 | 01:45 | |
| @clarkb:matrix.org | Cherry picking changes the sha. Maybe it is re enquing to reflect that the upstream state has changed | 01:54 |
| @iwienand:matrix.org | well pushing to docker.io/test/image doesn't seem to work either | 01:54 |
| @iwienand:matrix.org | https://zuul.opendev.org/t/zuul/build/68842987c3704d4f9464d07426698a25/console#3/6/10/ubuntu-focal | 01:54 |
| @iwienand:matrix.org | then get unauthorized on the pull, suggesting it's actually going to dockerhub | 01:58 |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul-jobs] 831323: configure-mirrors: fix stripped newline https://review.opendev.org/c/zuul/zuul-jobs/+/831323 | 03:56 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831135: Update testing to Ubuntu Focal https://review.opendev.org/c/zuul/zuul-registry/+/831135 | 05:12 | |
| @iwienand:matrix.org | Clark: corvus the "leaked image" theory seems correct; although upon investigation it's not clear if it's a feature or a bug. I have filed https://github.com/containers/podman/issues/13383 | 06:29 |
| -@gerrit:opendev.org- Ian Wienand proposed: | 06:36 | |
| - [zuul/zuul-registry] 831135: Update testing to Ubuntu Focal https://review.opendev.org/c/zuul/zuul-registry/+/831135 | ||
| - [zuul/zuul-registry] 831339: podman: make sure we remove the pulled image https://review.opendev.org/c/zuul/zuul-registry/+/831339 | ||
| -@gerrit:opendev.org- wangxiyuan proposed: [zuul/zuul-jobs] 830706: Add openEuler to iptalbe firewall persist https://review.opendev.org/c/zuul/zuul-jobs/+/830706 | 06:47 | |
| -@gerrit:opendev.org- Dr. Jens Harbott proposed: [zuul/zuul-jobs] 831354: Don't enable pip mirror for Debian Buster https://review.opendev.org/c/zuul/zuul-jobs/+/831354 | 10:29 | |
| -@gerrit:opendev.org- Matthieu Huin https://matrix.to/#/@mhuin:matrix.org proposed: [zuul/zuul] 831222: GUI: Do not show sign-in button if no IdP is available https://review.opendev.org/c/zuul/zuul/+/831222 | 10:41 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Matthieu Huin https://matrix.to/#/@mhuin:matrix.org: [zuul/zuul] 831231: Doc: stress the role of HS256 authenticator https://review.opendev.org/c/zuul/zuul/+/831231 | 11:22 | |
| @jpew:matrix.org | Per the question I asked later yesterday: If gerrit is set to the "cherry-pick" submit type, does that mean that there is no point in speculatively gating? I just seems to rebuild everything again anytime something changes.... or I'm missing some configuration thing? | 14:26 |
| @avass:vassast.org | jpew: reading the gerrit docs I'm guessing it's possible to enqueue changes in the "wrong order" since gerrit ignores dependencies between changes unless `change.submitWholeTopic` is configured and maybe zuul doesn't handle that well | 14:45 |
| @avass:vassast.org | but that's just a wild guess | 14:46 |
| @fungicide:matrix.org | jpew: i wouldn't rule out the possibility that there are few users relying on gerrit's cherry-pick submit type with zuul. the way the dependent pipeline manager works, i have a feeling the merge submit types are the only ones which will gate reliably as those closely match how zuul constructs its own refs and they don't alter the commits on submit. i know people have brought up similar problems with the rebase and fast-forward-only submit types (the former because they revise the commit which was tested similar to cherry-pick, and the latter because it doesn't allow reordering of changes) | 15:02 |
| @avass:vassast.org | fungi: i think I used `rebase if necessary` a lot previously and i don't think we experienced any issues with that. Though I'm currently trying to figure out some issues with `cherry-pick` | 15:05 |
| @avass:vassast.org | but cherry-pick could maybe be causing zuul to rebuild the gate queue since gerrit creates a new patch-set to add commit message footers and merges that instead of what was actually tested | 15:08 |
| @clarkb:matrix.org | Albin Vass: note that a cherry pick always implies a new sha because it will update the timestamp on the commit. This means even if Gerrit didn't update the message footers you would likely have the same issue. | 15:10 |
| @avass:vassast.org | Clark: true | 15:10 |
| @clarkb:matrix.org | This is a common source of confusion for us with people using git-review -x to reconstruct stacks of changes. They are surprised when every change updates in Gerrit and not just the child most they edited by hand too. | 15:11 |
| @clarkb:matrix.org | That said I wonder if Gerrit could represent it not as a new patchset which is likely the part that confuses Zuul since only the most recent patchset is mergeable | 15:14 |
| @avass:vassast.org | I also saw an issue where zuul had set up the wrong speculative state with cherry-pick but still ran the gate pipeline and succeeded, then failed to merged (luckily) because gerrit was reporting a merge conflict while zuul didn't detect it. | 15:14 |
| @avass:vassast.org | haven't been able to reproduce that though, but I think it was specifically when there was a commit dependency and the dependency had already been merged (so the second change was dependent on an old patch-set). | 15:16 |
| @jpew:matrix.org | Hmm, that's unfortunate..... I guess I either need to change Gerrit, or limit my speculative gating window to 1 then? | 15:18 |
| @jpew:matrix.org | (Changing Gerrit is going to be a hard sell) | 15:19 |
| @dpawlik:matrix.org | Albin Vass: hey, could you check https://review.opendev.org/c/zuul/zuul-jobs/+/829533/ ? | 15:23 |
| @fungicide:matrix.org | jpew: since Albin Vass has experience with rebase submits working, that may mean there's hope for getting cherry-pick submits working too. since the gerrit docs indicate that both types create a new patchset/revision on the change, so this might just be a bug in the gerrit driver which nobody's worked out a fix for | 15:30 |
| @fungicide:matrix.org | * jpew: since Albin Vass has experience with rebase submits working, that may mean there's hope for getting cherry-pick submits working too. the gerrit docs indicate that both types create a new patchset/revision on the change, so this might just be a bug in the gerrit driver which nobody's worked out a fix for | 15:30 |
| @jpew:matrix.org | It's weird that it only fails when "stacked" | 15:30 |
| @avass:vassast.org | fungi: jpew I think we used `rebase if necessary` and not `rebase always`though | 15:31 |
| @avass:vassast.org | `rebase always` creates a new patch set while `rebase if necessary` doesn't | 15:31 |
| @fungicide:matrix.org | jpew: "stacked" meaning you have multiple changes in the gate pipeline at the same time, or that you have multiple changes depending on one another? | 15:32 |
| @jpew:matrix.org | multiple in the pipeline at the same time | 15:32 |
| @fungicide:matrix.org | Albin Vass: "rebase if necessary" creates a new patch set when necessary, just not when it's not necessary | 15:32 |
| @avass:vassast.org | huh | 15:32 |
| @avass:vassast.org | dpawlik: looking at it but I'm trying to figure out where `python_version` comes from in the Centos 9 test :) | 15:34 |
| @avass:vassast.org | fungi: how come `Always merge` or `Merge if necessary` doesn't cause zuul to rebuild the gate queue then since the merge commit in zuul and what gerrit creates should differ? | 15:36 |
| @avass:vassast.org | I guess zuul handles that somehow? | 15:36 |
| @avass:vassast.org | jpew: I don't think we're seeing the gate queue being rebuilt in zuul 2 using cherry-pick in gerrit right now | 15:37 |
| @jpew:matrix.org | Hmm, OK. Maybe it's something else then.... Why is the build being marked as ERROR, but all the jobs passed, and it merged | 15:38 |
| @jpew:matrix.org | The buildset is being marked as ERROR | 15:39 |
| @avass:vassast.org | maybe it succeeds reporting to gerrit and submits the change but fails just after that? | 15:40 |
| @jpew:matrix.org | It must | 15:40 |
| @avass:vassast.org | in a way so zuul thinks reporting failed | 15:40 |
| @clarkb:matrix.org | > <@avass:vassast.org> fungi: how come `Always merge` or `Merge if necessary` doesn't cause zuul to rebuild the gate queue then since the merge commit in zuul and what gerrit creates should differ? | 15:41 |
| There is no new patchset with merges. It is the new patchset that causes this problem I think. | ||
| @jpew:matrix.org | Ah, it must race with the new patchset being created by the gerrit cherry-pick | 15:42 |
| @jpew:matrix.org | Which make sense, when there is only one thing in the gate queue, the load is much lower so it beats gerrit. When it is merging speculatively, its doing other stuff and thus is more likely to see the new PS | 15:45 |
| @jpew:matrix.org | (all my zuul components are on one machine) | 15:45 |
| @jpew:matrix.org | I bet if I set `pipeline.require.<gerrit source>.current-patchset` to false it would fix it.... | 15:47 |
| @jpew:matrix.org | Or move it to the trigger `require-approval` instead of the `pipeline.require`.... although that could be bad if someone pushes a new patch while its gating? | 15:49 |
| @fungicide:matrix.org | yeah, for the driver, i think the trick will be finding a way to tell a user pushing a new revision before submit apart from gerrit pushing a new revision on submit | 15:53 |
| @fungicide:matrix.org | if that's really what's causing the problem | 15:54 |
| @fungicide:matrix.org | seems like it should be possible to create a test case for it in zuul's integration testing | 15:54 |
| @fungicide:matrix.org | or even a unit test if we have a good model for how that submit type behaves | 15:55 |
| -@gerrit:opendev.org- Zuul merged on behalf of Szymon Datko: [zuul/zuul-jobs] 829533: [ensure-python] Fix for CentOS/RHEL 9 packages https://review.opendev.org/c/zuul/zuul-jobs/+/829533 | 16:05 | |
| @jpew:matrix.org | It has the `SUBM` approval in gerrit | 16:12 |
| @jpew:matrix.org | Maybe that should just be ignored? | 16:12 |
| @clarkb:matrix.org | Zuulians if you have time for https://review.opendev.org/c/zuul/zuul-registry/+/831235 and its child that aims to address some problems with zuul-registry that opendev has found. I believe worst case we can fall back to zuul-registry 1.1.0 in zuul-jobs and anywhere else that needs it should this go sideways. | 16:50 |
| @clarkb:matrix.org | jpew: Gerrit should still prevent older patchsets from merging. That is a requirement on the Gerrit side that only the most recent patchset can merge. I suspect setting the current-patchset flag may fix this. The downside will be you have to wait for submit to fail after a new patchset is pushed rather than resetting sooner | 16:51 |
| @clarkb:matrix.org | that tradeoff may be worthwhile? | 16:51 |
| @jpew:matrix.org | Clark: Ya. I'd rather have it build ahead | 16:51 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831430: Dequeue items that can no longer merge https://review.opendev.org/c/zuul/zuul/+/831430 | 17:26 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831316: Check if job request is still queued before yielding https://review.opendev.org/c/zuul/zuul/+/831316 | 17:34 | |
| @jim:acmegating.com | tristanC: i have a report that the ansi escape codes [m and [K don't work with re-ansi -- it looks like it isn't handling the default values (eg [m == [0m). does that sound plausible? | 18:22 |
| @tristanc_:matrix.org | corvus: that is correct, let me fix that | 18:27 |
| @avass:vassast.org | > <@avass:vassast.org> Regarding: https://review.opendev.org/c/zuul/zuul/+/830840 | 18:29 |
| > I'm wondering if it's better to piggy back on `zuul_return` so it's possible do something similar do: | ||
| > | ||
| > ``` | ||
| > - zuul_return: | ||
| > data: | ||
| > retry: false | ||
| > | ||
| > - fail: | ||
| > msg: ... | ||
| > ``` | ||
| > | ||
| > which could also make it possible to set `retry: true` to retry more dynamically in a `run` or `post` playbook. | ||
| > Or if it's better to implement the "fail early" functionality with a dedicated `zuul_fail` module. | ||
| I'm most likely going to start implementing this in a day or two so if i could steal the attention from someone who has any opinion about this for a second that would be great. Just so it doesn't get shot down during review :) | ||
| @tristanc_:matrix.org | corvus: not sure what to do with [K. The spec says `clear from cursor to the end of the line`, but gnome-terminal seems to do a noop instead | 18:49 |
| @tristanc_:matrix.org | I guess we can interpret it as the current erase line code, here is the fix I can publish if you are ok with my interpretation: https://softwarefactory-project.io/r/c/software-factory/re-ansi/+/24175 | 18:56 |
| @clarkb:matrix.org | tristanC: 1K is erase from beginning of the line to cursor and 0K is from cursor to end of line. Is differentiating that behavior not possible for some reason? | 19:00 |
| @tristanc_:matrix.org | well it is possible, but i can't reproduce the behavior in my terminal, so i'm not sure it is relevant | 19:01 |
| @clarkb:matrix.org | I was reading a blog post about this recently and gnome-terminal is extremely buggy when it comes to this sort of thing. xterm is apparently the standard to compare against | 19:08 |
| @jim:acmegating.com | `foo bar^[[3D^[[Khi` is an example, right? that should show as `foo hi` | 19:11 |
| @jim:acmegating.com | whereas `foo bar ^[[3D^[[1Khi` renders as ` hir` | 19:12 |
| @jim:acmegating.com | * whereas `foo bar ^[[3D^[[1Khi` renders as `____hir` (edit: spaces to underscores for clarity in chat) | 19:13 |
| @jim:acmegating.com | * whereas `foo bar^[[3D^[[1Khi` renders as `____hir` (edit: spaces to underscores for clarity in chat) | 19:13 |
| @tristanc_:matrix.org | oh well that kind of cursor movement is currently not supported and it's unclear how to do it efficiently... | 19:15 |
| @jim:acmegating.com | maybe it's better to noop then? | 19:16 |
| @jim:acmegating.com | (or even leave the escape sequences unhandled, i guess like they are now?) | 19:17 |
| @tristanc_:matrix.org | from what I understand, [_K is used to update the current line, and erasing what was before seems to be good | 19:17 |
| @jim:acmegating.com | what is `_K` ? | 19:18 |
| @tristanc_:matrix.org | e.g. `[K` or `[1K`, or `[2K` | 19:19 |
| @tristanc_:matrix.org | i meant, unless it is an interactive program, then I can't imagine why a CI tool would erase forward | 19:20 |
| @jim:acmegating.com | ah. well, you could do "clear this line and start over" with either "[1K[G" or "[G[0K" | 19:21 |
| @tristanc_:matrix.org | right, and I think `[K` or `[0K` is often used after a `[G` to clear the previous output, thus I think it's fine to interpret this code as, drop the current line and starts over | 19:23 |
| @tristanc_:matrix.org | or even after a `\r` | 19:23 |
| @jim:acmegating.com | tristanC: i went and looked up the example that was reported to me -- it's `[1A[KStatus output` -- that's repeated after a \n. so basically the \n is returning to column 1, then the 1A moves up to the line, then [K clears it. | 19:28 |
| @jim:acmegating.com | so that particular case, since it's showing up on multiple log lines anyway, it doesn't matter. a noop or clear-to-start would work equally well. | 19:28 |
| @tristanc_:matrix.org | if necessary i can look into adding support for `\[1A`, but that would require a bit of overhead to be able to reach the previous line, thus if that's ok, i prefer to go forward with the simplest solution. | 19:30 |
| @jim:acmegating.com | i think i'd lean toward doing a noop for anything you don't want to implement, but that's because i have a bias towards maximum information. | 19:31 |
| @jim:acmegating.com | tristanC: yeah, if i were in your position, i probably wouldn't implement the movement characters at all, and maybe even stop handling [1K | 19:31 |
| @jim:acmegating.com | (i definitely agree with wanting to keep it simple. and to be clear, i don't think the current [K handling is bothering anyone -- just reporting that observation for completeness) | 19:36 |
| @jim:acmegating.com | ([m can be a problem though as it can produce weird/illegible color output) | 19:37 |
| -@gerrit:opendev.org- Ian Wienand proposed: | 19:46 | |
| - [zuul/zuul-registry] 831319: podman buildset testing: dump image list https://review.opendev.org/c/zuul/zuul-registry/+/831319 | ||
| - [zuul/zuul-registry] 831339: podman: make sure we remove the pulled image https://review.opendev.org/c/zuul/zuul-registry/+/831339 | ||
| - [zuul/zuul-registry] 831135: Update testing to Ubuntu Focal https://review.opendev.org/c/zuul/zuul-registry/+/831135 | ||
| - [zuul/zuul-registry] 831440: Fix and/or matching for image pre-conditions https://review.opendev.org/c/zuul/zuul-registry/+/831440 | ||
| -@gerrit:opendev.org- Dr. Jens Harbott proposed: [zuul/zuul-jobs] 831443: Fix ensure-pip test on Debian Buster https://review.opendev.org/c/zuul/zuul-jobs/+/831443 | 20:13 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/nodepool] 831108: Update to DIB 3.19.1 https://review.opendev.org/c/zuul/nodepool/+/831108 | 20:34 | |
| -@gerrit:opendev.org- Ian Wienand proposed: | 20:39 | |
| - [zuul/zuul-registry] 831440: Fix and/or matching for image pre-conditions https://review.opendev.org/c/zuul/zuul-registry/+/831440 | ||
| - [zuul/zuul-registry] 831135: Update testing to Ubuntu Focal https://review.opendev.org/c/zuul/zuul-registry/+/831135 | ||
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul] 831450: web: bump re-ansi version https://review.opendev.org/c/zuul/zuul/+/831450 | 20:53 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 20:56 | |
| @jim:acmegating.com | tristanC: thanks, +2! | 20:59 |
| @clarkb:matrix.org | tristanC: corvus do we want to check that on the preview site before approving or should I +A? | 21:00 |
| @jim:acmegating.com | maybe we could sanity check it against a docker build or something? i think that gets color and movement... | 21:02 |
| @tristanc_:matrix.org | good idea, let me see, i think there is a change for that | 21:02 |
| @clarkb:matrix.org | sounds good I +2'd so we can +A it once we've checked one of those | 21:02 |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul-jobs] 763054: DNM: generate ansi log for benchmark purpose https://review.opendev.org/c/zuul/zuul-jobs/+/763054 | 21:07 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 831430: Dequeue items that can no longer merge https://review.opendev.org/c/zuul/zuul/+/831430 | 21:09 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 21:26 | |
| -@gerrit:opendev.org- Tristan Cacqueray proposed: [zuul/zuul] 831453: web: enable re-ansi in the logfile view https://review.opendev.org/c/zuul/zuul/+/831453 | 21:54 | |
| @iwienand:matrix.org | well this is a silly and annoying line : https://cs.opensource.google/go/x/net/+/master:http/httpproxy/proxy.go;l=185 | 22:25 |
| @iwienand:matrix.org | i'm not sure why go is the only environment they does not obey http_proxy to a local address | 22:26 |
| @iwienand:matrix.org | https://github.com/golang/go/issues/51416 we'll see if anyone cares/agrees/disagrees I guess. | 22:51 |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 23:20 | |
| -@gerrit:opendev.org- Ian Wienand proposed: [zuul/zuul-registry] 831131: [WIP] Enable mitmproxy between docker/podman to dump test https://review.opendev.org/c/zuul/zuul-registry/+/831131 | 23:36 | |
| @clarkb:matrix.org | corvus: couple of thoughts on the stack at https://review.opendev.org/c/zuul/zuul/+/830925 | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!