| *** shanemcd has quit IRC | 00:03 | |
| *** shanemcd has joined #zuul | 00:04 | |
| *** jamesmcarthur has quit IRC | 00:08 | |
| *** jamesmcarthur has joined #zuul | 00:17 | |
| *** jamesmcarthur has quit IRC | 00:31 | |
| *** jamesmcarthur has joined #zuul | 00:32 | |
| *** jamesmcarthur has quit IRC | 01:14 | |
| *** jamesmcarthur has joined #zuul | 01:17 | |
| *** ianychoi has quit IRC | 01:17 | |
| *** ianychoi has joined #zuul | 01:18 | |
| *** jamesmcarthur has quit IRC | 01:22 | |
| *** igordc has quit IRC | 01:26 | |
| *** jamesmcarthur has joined #zuul | 01:40 | |
| *** jamesmcarthur has quit IRC | 02:06 | |
| *** jamesmcarthur has joined #zuul | 02:07 | |
| *** bhavikdbavishi has joined #zuul | 03:12 | |
| *** raukadah is now known as chandankumar | 03:23 | |
| *** spsurya has joined #zuul | 03:29 | |
| *** bhavikdbavishi1 has joined #zuul | 03:31 | |
| *** bhavikdbavishi has quit IRC | 03:32 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:32 | |
| *** igordc has joined #zuul | 03:58 | |
| *** ianychoi has quit IRC | 03:59 | |
| *** ianychoi has joined #zuul | 04:00 | |
| *** bolg has joined #zuul | 04:03 | |
| *** bolg has quit IRC | 04:13 | |
| *** rfolco has quit IRC | 04:17 | |
| *** bolg has joined #zuul | 04:20 | |
| *** jamesmcarthur has quit IRC | 04:31 | |
| *** jamesmcarthur has joined #zuul | 04:33 | |
| *** spsurya has quit IRC | 04:37 | |
| *** spsurya has joined #zuul | 04:38 | |
| *** pcaruana has joined #zuul | 05:01 | |
| *** ianychoi has quit IRC | 05:03 | |
| *** ianychoi has joined #zuul | 05:05 | |
| *** jamesmcarthur has quit IRC | 05:17 | |
| *** ianychoi has quit IRC | 05:27 | |
| *** ianychoi has joined #zuul | 05:29 | |
| *** bolg has quit IRC | 05:29 | |
| *** jamesmcarthur has joined #zuul | 05:47 | |
| *** igordc has quit IRC | 05:52 | |
| *** ianychoi has quit IRC | 06:00 | |
| *** ianychoi has joined #zuul | 06:01 | |
| *** bolg has joined #zuul | 06:11 | |
| *** bolg has quit IRC | 06:18 | |
| *** jamesmcarthur has quit IRC | 06:20 | |
| *** jamesmcarthur has joined #zuul | 06:28 | |
| *** ianychoi has quit IRC | 06:40 | |
| *** ianychoi has joined #zuul | 06:42 | |
| openstackgerrit | Ian Wienand proposed zuul/nodepool master: dib-functional : allow extra elements to be passed https://review.opendev.org/685884 | 06:44 |
|---|---|---|
| *** bhavikdbavishi has quit IRC | 06:48 | |
| *** hashar has joined #zuul | 06:58 | |
| *** themroc has joined #zuul | 07:01 | |
| *** jamesmcarthur has quit IRC | 07:04 | |
| *** zbr is now known as zbr|ruck | 07:08 | |
| *** brendangalloway has joined #zuul | 07:12 | |
| *** tosky has joined #zuul | 07:16 | |
| *** recheck has quit IRC | 07:27 | |
| *** recheck has joined #zuul | 07:28 | |
| *** badboy has joined #zuul | 07:29 | |
| badboy | is it possible to set timezone offset in the build section of the web console? | 07:30 |
| *** jpena|off is now known as jpena | 07:43 | |
| *** jangutter has quit IRC | 07:56 | |
| *** hashar has quit IRC | 08:05 | |
| *** jangutter has joined #zuul | 08:14 | |
| *** yolanda has joined #zuul | 08:23 | |
| *** hashar has joined #zuul | 08:51 | |
| *** jamesmcarthur has joined #zuul | 09:01 | |
| tosky | mordred: hi, question about fetch-subunit-output (related to this old review https://review.opendev.org/#/c/534431/ ) - do I understand the code correctly that tox_envlist is no more used? | 09:04 |
| *** jamesmcarthur has quit IRC | 09:06 | |
| mordred | tosky: yeah. I mean - tox_envlist is still used in the tox jobs, but the value of tox_envlist is no longer used by fetch-subunit-output - that now just looks for all of the tox output available with the find command | 09:15 |
| *** bhavikdbavishi has joined #zuul | 09:27 | |
| mhu | mordred, hi, I have a question about tox_install_sibling_packages.py in the tox jobs | 09:28 |
| mhu | it does not seem to install siblings if they are not present in tox's venv after the first dry run | 09:29 |
| mhu | is that normal? | 09:29 |
| *** rfolco has joined #zuul | 09:29 | |
| mhu | or more generally speaking, how is the "required-projects" supposed to work with a tox job? | 09:30 |
| mordred | mhu: yes - it's trying to use the dry run to figure out which of the sibling git repos it should attempt to install | 09:30 |
| mordred | so - adding a project to required-projects should cause it to be installed into the tox env if it's a library tox woudl normally install | 09:31 |
| mordred | but if it's not, like, say for instance, openstack/requirements - then it should get skipped | 09:31 |
| mhu | mordred, ah gotcha! | 09:32 |
| mhu | thanks, I think I see what I was doing wrong | 09:32 |
| mordred | \o/ | 09:32 |
| *** bhavikdbavishi1 has joined #zuul | 09:35 | |
| *** bhavikdbavishi has quit IRC | 09:37 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 09:37 | |
| *** hashar has quit IRC | 09:43 | |
| *** hashar has joined #zuul | 09:45 | |
| mhu | mordred, so I am trying to set up a demo of 2 python projects, let's say A and LibA (A depends on LibA) I want to have a common tox job for both projects that always runs tox on A (so that I can see if a change on LibA breaks A) | 09:54 |
| mhu | is it possible to use the default tox-py* jobs for that? Maybe by overriding the zuul_working_dir var? | 09:55 |
| mhu | or should I rewrite a tox-like job? | 09:55 |
| mhu | seems like the var override is doing the trick, but if you have a better way to do it I'll gladly take it | 09:58 |
| mordred | mhu: no, I think the override of zuul_work_dir is the right way to go there | 10:05 |
| mordred | mhu: I think mnaser has a similar demo he was using at the vexxhost booth at ansiblefest - it seems like a really good demo case to make people get it | 10:06 |
| mordred | mhu: it's a slightly larger example - but https://opendev.org/openstack/shade/src/branch/master/.zuul.yaml#L1-L15 is us doing that same pattern in shade | 10:08 |
| mhu | mordred, ah noice! I'm doing this for a blog post but that's something I could add to the OSS talk at the end of the month | 10:09 |
| mordred | ++ | 10:13 |
| *** bhavikdbavishi has quit IRC | 10:45 | |
| openstackgerrit | Merged zuul/zuul master: Replace tox-py36 by tox-py37 https://review.opendev.org/682158 | 10:47 |
| tosky | mordred: thanks; I'm trying to write a test for that role (to push forward https://review.opendev.org/#/c/674334/) and being able to ignore one variable is useful | 10:50 |
| *** avass has joined #zuul | 11:05 | |
| *** jpena is now known as jpena|lunch | 11:38 | |
| *** bolg has joined #zuul | 11:49 | |
| *** frickler has joined #zuul | 12:03 | |
| *** ianychoi has quit IRC | 12:10 | |
| *** ianychoi has joined #zuul | 12:13 | |
| *** fdegir has quit IRC | 12:21 | |
| *** fdegir has joined #zuul | 12:22 | |
| *** jpena|lunch is now known as jpena | 12:38 | |
| *** badboy has quit IRC | 12:41 | |
| *** fdegir has quit IRC | 12:45 | |
| *** fdegir has joined #zuul | 12:45 | |
| *** themroc has quit IRC | 13:11 | |
| *** avass has quit IRC | 13:34 | |
| *** michael-beaver has joined #zuul | 13:42 | |
| brendangalloway | Does a roles folder need to live in the root of a project in order for other projects to be able to import them? | 13:43 |
| pabelanger | brendangalloway: https://zuul-ci.org/docs/zuul/user/config.html#attr-job.roles should help. Explains how we load roles in jobs | 13:45 |
| brendangalloway | pabelanger: Ok, so they won't be picked up if they're in playbook/roles? That's where most of our roles live at the moment to make it easier to test the playbooks out-of-zuul | 13:48 |
| brendangalloway | pabelanger: Also, while you're online. You previously advised to try a meta: connection_reset to help with our pxe boot reconnection issue. That did not help, any other advice? | 13:49 |
| pabelanger | brendangalloway: yah, top level roles is usually what I do, as that way can 'release' it to galaxy if wanted for projects outside of zuul. But inside roles/ folder also works | 13:52 |
| pabelanger | brendangalloway: I think next step is to get packet trace (tcpdump) to better understand what is happening on network. | 13:53 |
| brendangalloway | pabelanger: Would symlinking roles->playbooks/roles fix the issue? | 13:53 |
| pabelanger | should, if in the same repo | 13:54 |
| pabelanger | roles next to playbooks should load without issue | 13:54 |
| brendangalloway | pabelanger: ok, we can get a packet capture going | 13:55 |
| pabelanger | ++ | 13:56 |
| brendangalloway | one final question. We're trying to get a release pipeline going. It's currently in a branch, but the branchmatcher is not returning that branch when it checks where to run | 14:00 |
| fungi | brendangalloway: release via git tags? tags are not directly related to branches in git, which leads to some conceptual challenges with the way they're often treated | 14:01 |
| fungi | https://review.opendev.org/578557 is a proposal for guessing the most appropriate branch for a given tag, but use some additional feedback and confirmation that it would be useful to users to make that tenuous connection | 14:03 |
| brendangalloway | fungi: with git tags yes, to trigger /refs/tags/ as per the pipeline that ships with zuul | 14:04 |
| fungi | er, could use some additional feedback | 14:04 |
| fungi | yeah, the short story there is that a tag can refer to a ref in the history of multiple branches or even none, so to pretend there's a particular branch for a tag is a bit of a stretch | 14:05 |
| fungi | but it's a stretch we could have zuul make, if there's some consensus that it's warranted by popular workflows | 14:05 |
| brendangalloway | That could be an issue yes. In our scenario the commit exists only in the one specific branch. That's also the only branch where the pipeline is actually defined. | 14:07 |
| brendangalloway | Is it still expected to return a single match in such a scenario? | 14:09 |
| fungi | if the jobs you trigger from refs/tags/* don't have an explicit branch matcher in them, then they should run | 14:09 |
| fungi | zuul ought to load job definitions from all available branches of the repository, so should be aware that the job is supposed to be triggered on that refname pattern | 14:10 |
| brendangalloway | explicit branch matcher being a job.branches variable? | 14:11 |
| fungi | yeah, if the job definition includes an explicit branch matcher, then zuul will see that the tag event doesn't have any associated branch data and will decide the job is not supposed to be run | 14:11 |
| brendangalloway | No branches variable in the job. We actually tried to add one so that the job definition in that branch declares it should be run in that branch to try force it without any success | 14:13 |
| fungi | that'll have the reverse of the desired effect, since the tag ref won't be considered to match any branch | 14:14 |
| fungi | in opendev i think all our tag jobs are defined in a branchless repo... maybe the implicit branch match for the configuration (due to being in a branched repository) is having a similar effect? | 14:15 |
| fungi | anyone happen to know if implicit branch matching will cause jobs triggered from tag refs not to be considered? | 14:16 |
| brendangalloway | ok, that makes sense. Even without the branch decleration the matchers trigger, then report not matching any of the branches | 14:16 |
| brendangalloway | I think the job is defined in maybe three of the branches (release branches implemented since zuul was turned on) | 14:17 |
| fungi | i see in opendev's infrastructure manual we've documented: 'There are several notable exceptions for job configs that should remain in the central config repository [...] Jobs that are not “branch aware”. Typically these are jobs that are triggered by tag based events.' https://docs.openstack.org/infra/manual/creators.html#central-config-exceptions | 14:25 |
| fungi | this suggests to me that we likely defined tag-triggered jobs in a branchless repo as a workaround for that behavior | 14:28 |
| AJaeger | fungi: correct, that's why we left all the publish-to-pypi in project-config which is branchless | 14:28 |
| brendangalloway | ok, that makes sense. I'm guessing the tag-triggered jobs never need some sort of point-in-time release branch put in place then? | 14:34 |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Initial implementation https://review.opendev.org/683958 | 14:34 |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Fix container image build https://review.opendev.org/685808 | 14:34 |
| fungi | brendangalloway: by "point-in-time release branch" i assume you mean branch-specific behaviors in tag-triggered jobs... in a few cases we have logic embedded in the jobs themselves to guess a relevant branch based on some heuristic and alter behavior accordingly, but the https://review.opendev.org/578557 implementation sounds more like what you're talking about i think | 14:37 |
| fungi | if memory serves, that would provide a means for zuul to use its branch matcher logic in combination with a guessed branch for a tag, and apply the jobs configured in the branch it has associated with the tag, so that your tag-triggered release jobs can themselves branch over time | 14:38 |
| brendangalloway | Well branch specific in the sense of "that's what the builder system was doing in v1.1" | 14:39 |
| fungi | right, i believe that's what https://review.opendev.org/578557 would try to provide | 14:39 |
| brendangalloway | Ok, that would be great | 14:40 |
| fungi | more reviews of that change, even at just a conceptual level, would be appreciated | 14:40 |
| brendangalloway | But in them meantime tagged jobs only work when no branches are present? | 14:40 |
| fungi | that's what i'm coming to realize, yes | 14:40 |
| *** bhavikdbavishi has joined #zuul | 14:41 | |
| brendangalloway | ok - using a tagged release was to 1) pass some info to the builder regarding some branding actions that need to be applied 2) Allow for build to be triggered without needing a dummy review or zuul enqueue | 14:42 |
| fungi | right now we're still assuming that different communities/organizations may have workflows where the heuristics we think could be a relevant way to guess the branch of a tag don't work, since the data model of git doesn't itself have any direct tie between those two sorts of handles | 14:42 |
| brendangalloway | Not sure how to provide those functions without a tag | 14:43 |
| *** gtema_ has joined #zuul | 14:45 | |
| fungi | i'm not sure whether it's relevant for your jobs, but you could for example build those artifacts on each new branch state in the context of a branch-relevant triggering event and then merely anoint them with release-specific details when the corresponding ref for one is tagged | 14:45 |
| mordred | corvus: I just left a useless comment on the second zuul-registry change. it was sort of stream of consciousenss from me as I was reviewing, then I realized I was wrong. | 14:46 |
| brendangalloway | fungi: The problem is we have a baseline product, that then has some branding actions applied at build time depending on which customer is next expecting a release - building for all customers every release will become burdensome | 14:47 |
| fungi | brendangalloway: but i agree, it would be nice not to have to jump through such hoops. one reason we're interested in this feature for opendev is that openstack periodically transitions its base test platform as newer operating systems become available, but maintains stable release branches for a long period of time. we'd like to be able to easily configure jobs so that tag-triggered release jobs on different | 14:48 |
| fungi | branches run on the platforms which were contemporary with when those branches were created | 14:48 |
| brendangalloway | Our artefacts are also really really big | 14:49 |
| fungi | instead, currently, we generate some point releases on platforms which are newer than the ones those branches are otherwise running jobs on, which leaves us at a risk of having those release jobs spontaneously break due to changes in behavior for those platforms | 14:50 |
| brendangalloway | It sounds like your work-in-progress solution is what we're hoping for, trying to determine what to do in the meantime | 14:50 |
| clarkb | brendangalloway: you can have the job take different action based on the tag value itself. THis works as long as you don't need to change job details like nodeset | 14:51 |
| fungi | yeah, if the differences you need to apply are present in the correct repository branches then those will still be what's checked out on disk for the builds | 14:52 |
| fungi | though also if these jobs integrate multiple repositories, you still have the challenge of determining what state to check out for the other repositories which aren't the one which got the tag | 14:53 |
| fungi | basically, zuul should provide you with a reopsitory checked out to the tag ref | 14:54 |
| *** jamesmcarthur has joined #zuul | 14:55 | |
| Shrews | corvus: i left a couple of comments on the initial registry change. none are -1 worthy | 14:55 |
| Shrews | i like the abstract driver class \o/ | 14:55 |
| corvus | Shrews: yay! | 14:55 |
| brendangalloway | They job is also integrating multiple repos, but both should be branched at the same time (and hopefully merged at some point) | 14:55 |
| corvus | Shrews: replied. is it + worthy? :) | 14:59 |
| Shrews | corvus: so, cat_objects() will concatenate those objects saved via put_object(), yeah? | 15:00 |
| corvus | Shrews: yes (but after move_object) | 15:01 |
| *** bhavikdbavishi has quit IRC | 15:02 | |
| corvus | Shrews: put: /uploads/uuid/1; move: uploads/uuid/1 -> /blobs/sha/1; cat /blobs/sha/1 -> blobs/sha/data | 15:02 |
| Shrews | corvus: this is the exact situation we had in nodepool-builder where we were leaking objects. we often see the concat fail in rax (even after retries). I added code to sdk to manually cleanup those images, and also used the delete header. I don't see us handling that situation. | 15:02 |
| corvus | Shrews: that's what the prune command is for | 15:02 |
| Shrews | where is this prune command? i must have missed it. can't find it offhand | 15:03 |
| Shrews | oh, docker image prune ? | 15:05 |
| corvus | Shrews: line 237 of storage.py | 15:05 |
| corvus | Shrews: invoked by 'zuul-registry prune' | 15:05 |
| corvus | if something goes wrong with finalizing the upload, we'll end up with objects either in the uploads/ or blobs/ tree which aren't referenced by a valid manifest, so the prune will delete them | 15:06 |
| corvus | oh i just caught something.... | 15:08 |
| *** bhavikdbavishi has joined #zuul | 15:09 | |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Initial implementation https://review.opendev.org/683958 | 15:10 |
| openstackgerrit | James E. Blair proposed zuul/zuul-registry master: Fix container image build https://review.opendev.org/685808 | 15:10 |
| openstackgerrit | Fabien Boucher proposed zuul/zuul master: WIP - Gitlab - Basic handling of merge_requests event https://review.opendev.org/685990 | 15:12 |
| *** ianychoi has quit IRC | 15:20 | |
| Shrews | corvus: +2 with comment | 15:22 |
| *** ianychoi has joined #zuul | 15:23 | |
| corvus | Shrews: yeah, and i think there's opportunity for making uploads/downloads from swift more efficient | 15:25 |
| *** mattw4 has joined #zuul | 15:32 | |
| *** bolg has quit IRC | 15:34 | |
| *** jpena is now known as jpena|brb | 15:42 | |
| *** bhavikdbavishi1 has joined #zuul | 15:46 | |
| *** bhavikdbavishi has quit IRC | 15:48 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 15:48 | |
| brendangalloway | pabelanger: we grabbed a packet capture. ssh key exchange occurs, 5 encrypted packets are transferred and then there's a FYN. That repeats in a loop until the job times out | 15:50 |
| *** hashar has quit IRC | 15:55 | |
| *** brendangalloway has quit IRC | 16:01 | |
| openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Revert "Use import_role on persistent-firewall" https://review.opendev.org/685996 | 16:11 |
| clarkb | corvus: ^ fyi e-r shows occurences well after we updated the role | 16:11 |
| *** gtema_ has quit IRC | 16:12 | |
| clarkb | the other idea I had was to change command to shell then maybe we can add more debugging like shell: iptables-save || echo "return value $?" ? | 16:12 |
| *** jpena|brb is now known as jpena | 16:19 | |
| corvus | clarkb: do we have the output? or does everything look okay it's just a weird exit code? | 16:20 |
| clarkb | it says to look at output but we don't get any | 16:20 |
| fungi | also the modification you're proposing to the shell task would mask the failures | 16:20 |
| clarkb | fungi: we already mask the failures with failed_when: false | 16:20 |
| fungi | ahh | 16:21 |
| clarkb | this is why the jobs don't fail until they try to use the stdout from that command task | 16:21 |
| fungi | shell: iptables-save || iptables -L | 16:21 |
| fungi | maybe? | 16:22 |
| openstackgerrit | Jimmy McArthur proposed zuul/zuul-website master: CSS fix for ul/li in FAQ https://review.opendev.org/686003 | 16:31 |
| *** jpena is now known as jpena|off | 17:16 | |
| AJaeger | team, are we ready to merge https://review.opendev.org/#/c/567696/ - "Allow upload-logs to toggle compression of console logs" for zuul-jobs? | 17:24 |
| AJaeger | I'll approve in an hour if I hear nothing otherwise, it should not hit opendev and has been announced... | 17:27 |
| *** igordc has joined #zuul | 17:37 | |
| *** jamesmcarthur has quit IRC | 17:38 | |
| *** jamesmcarthur has joined #zuul | 17:48 | |
| pabelanger | So, who do I need to bribe to help add pagination support to builds UI? Or date range support for searching | 17:58 |
| *** jamesmcarthur has quit IRC | 17:59 | |
| *** jamesmcarthur has joined #zuul | 17:59 | |
| *** jamesmcarthur has quit IRC | 18:04 | |
| corvus | pabelanger: you could start by checking if the rest api supports that, since that would be a pre-req for the js | 18:11 |
| *** jamesmcarthur has joined #zuul | 18:19 | |
| *** jamesmcarthur has quit IRC | 18:23 | |
| tristanC | pabelanger: corvus: pagination could be implemented using the skip argument (documented in http://zuul.opendev.org/openapi ). Date range is missing from the api. | 18:30 |
| pabelanger | OMG, that is a thing? | 18:30 |
| pabelanger | that is awesome | 18:31 |
| pabelanger | Hmm, openapi doesn't seem to work locally. Need to debug why | 18:34 |
| pabelanger | that at least gives me a way to manually craft some urls | 18:34 |
| *** fabdultf has joined #zuul | 18:35 | |
| tristanC | pabelanger: what is not working? | 18:36 |
| tristanC | it seems like path parameter are not correctly handled by the execute button, but when using whitelabeled version, it works fine: http://zuul.openstack.org/openapi | 18:39 |
| openstackgerrit | Merged zuul/zuul-jobs master: Revert "Use import_role on persistent-firewall" https://review.opendev.org/685996 | 18:42 |
| *** jamesmcarthur has joined #zuul | 18:47 | |
| pabelanger | tristanC: yah, execute button isn't doing anything. Not sure why | 18:50 |
| pabelanger | even if I add a tenant | 18:50 |
| openstackgerrit | Merged zuul/zuul-jobs master: Allow upload-logs to toggle compression of console logs https://review.opendev.org/567696 | 18:56 |
| *** spsurya has quit IRC | 19:09 | |
| mnaser | mhu, mordred: sorry, i can make that repo public actually, it doesnt have anything magical | 19:13 |
| mnaser | i dont have a documented "how to do the demo" thing | 19:13 |
| mnaser | mhu, mordred: but this is how i setup a very simple tox cross-repo job. https://www.irccloud.com/pastebin/fQdKYQC2/ | 19:14 |
| openstackgerrit | Mohammed Naser proposed zuul/zuul-jobs master: Add unit tests for tox_instalL_sibling_packages https://review.opendev.org/683963 | 19:18 |
| *** Miouge has quit IRC | 19:38 | |
| *** Miouge has joined #zuul | 19:38 | |
| openstackgerrit | Merged zuul/zuul-jobs master: Add unit tests for tox_instalL_sibling_packages https://review.opendev.org/683963 | 19:42 |
| *** dkehn has joined #zuul | 19:48 | |
| *** fdegir has quit IRC | 19:54 | |
| *** fdegir has joined #zuul | 19:55 | |
| *** jamesmcarthur has quit IRC | 20:07 | |
| *** jamesmcarthur has joined #zuul | 20:16 | |
| *** fabdultf has quit IRC | 20:17 | |
| *** pcaruana has quit IRC | 20:33 | |
| *** openstackstatus has quit IRC | 21:32 | |
| *** openstackstatus has joined #zuul | 21:35 | |
| *** ChanServ sets mode: +v openstackstatus | 21:35 | |
| openstackgerrit | Clark Boylan proposed zuul/zuul master: Always use change url from gerrit api data https://review.opendev.org/686054 | 21:47 |
| openstackgerrit | Clark Boylan proposed zuul/zuul master: Set url scheme on HTTP Gerrit events https://review.opendev.org/686054 | 22:13 |
| *** sgw has quit IRC | 22:42 | |
| *** sgw has joined #zuul | 22:43 | |
| *** armstrongs has joined #zuul | 22:45 | |
| *** jamesmcarthur has quit IRC | 22:48 | |
| *** armstrongs has quit IRC | 22:55 | |
| *** tosky has quit IRC | 23:02 | |
| openstackgerrit | Clark Boylan proposed zuul/zuul master: Set url scheme on HTTP Gerrit events https://review.opendev.org/686054 | 23:02 |
| openstackgerrit | Clark Boylan proposed zuul/zuul master: Handle new default of uncompressed job-output https://review.opendev.org/686072 | 23:02 |
| *** jamesmcarthur has joined #zuul | 23:32 | |
| openstackgerrit | Merged zuul/zuul master: Handle new default of uncompressed job-output https://review.opendev.org/686072 | 23:54 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!