*** rfolco|rover has joined #zuul | 00:20 | |
ianw | nup ... i dunno | 00:20 |
---|---|---|
*** rfolco|rover has quit IRC | 00:25 | |
*** ysandeep|away is now known as ysandeep | 00:28 | |
jkt | yay, a first cross-project build has just passed | 00:41 |
jkt | now let's get some caching into the mix so that it doesn't rebuild that full embedded linux image, including the kernel | 00:41 |
*** Goneri has quit IRC | 01:11 | |
*** swest has quit IRC | 01:45 | |
*** jpena|off has quit IRC | 01:52 | |
*** swest has joined #zuul | 02:01 | |
*** bhavikdbavishi has joined #zuul | 02:14 | |
*** bhavikdbavishi1 has joined #zuul | 02:45 | |
*** bhavikdbavishi has quit IRC | 02:46 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 02:46 | |
openstackgerrit | Oleksandr Kozachenko proposed zuul/zuul-jobs master: Patch CoreDNS corefile https://review.opendev.org/727868 | 03:23 |
*** zxiiro has quit IRC | 03:57 | |
*** evrardjp has quit IRC | 04:36 | |
*** evrardjp has joined #zuul | 04:36 | |
*** felixedel has joined #zuul | 05:10 | |
*** sgw has quit IRC | 05:18 | |
*** bhavikdbavishi has quit IRC | 05:20 | |
*** reiterative has quit IRC | 05:37 | |
*** bhavikdbavishi has joined #zuul | 05:37 | |
*** reiterative has joined #zuul | 05:37 | |
openstackgerrit | Felix Edel proposed zuul/zuul master: Report dequeued changes via Github checks API https://review.opendev.org/711023 | 05:42 |
openstackgerrit | Oleksandr Kozachenko proposed zuul/zuul-jobs master: Add container and pod log in the test for ensure-kubernetes role https://review.opendev.org/727929 | 05:43 |
*** dpawlik has joined #zuul | 06:06 | |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: WIP: Warn user when dynamic layout ignores zuul config https://review.opendev.org/720249 | 06:13 |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Warn user when dynamic layout ignores zuul config https://review.opendev.org/720249 | 06:30 |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Drop support for ansible 2.7 https://review.opendev.org/727373 | 06:33 |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Update images to use python 3.8 https://review.opendev.org/727374 | 06:34 |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Drop support for ansible 2.6 https://review.opendev.org/727157 | 06:42 |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Drop support for ansible 2.7 https://review.opendev.org/727373 | 06:42 |
openstackgerrit | Tobias Henkel proposed zuul/zuul master: Update images to use python 3.8 https://review.opendev.org/727374 | 06:42 |
openstackgerrit | Oleksandr Kozachenko proposed zuul/zuul-jobs master: Patch CoreDNS corefile https://review.opendev.org/727868 | 06:55 |
openstackgerrit | Oleksandr Kozachenko proposed zuul/zuul-jobs master: Add container and pod log in the test for ensure-kubernetes role https://review.opendev.org/727929 | 06:55 |
*** jcapitao has joined #zuul | 07:10 | |
*** bhavikdbavishi has quit IRC | 07:14 | |
*** guillaumec has joined #zuul | 07:31 | |
*** tosky has joined #zuul | 07:31 | |
*** rpittau|afk is now known as rpittau | 07:33 | |
*** harrymichal has joined #zuul | 07:39 | |
*** fbo|off is now known as fbo|afk | 07:41 | |
*** bhavikdbavishi has joined #zuul | 07:44 | |
openstackgerrit | Tobias Henkel proposed zuul/nodepool master: WIP: Azure api versions https://review.opendev.org/727958 | 07:50 |
*** jpena has joined #zuul | 07:57 | |
*** guillaumec has quit IRC | 08:04 | |
*** ysandeep is now known as ysandeep|lunch | 08:14 | |
*** nils has joined #zuul | 08:17 | |
*** harrymichal has quit IRC | 08:40 | |
*** dpawlik has quit IRC | 08:40 | |
openstackgerrit | Sorin Sbarnea (zbr) proposed zuul/zuul-jobs master: yamlint: EOF newlines and comments indent https://review.opendev.org/725516 | 08:42 |
*** dpawlik has joined #zuul | 08:45 | |
*** ysandeep|lunch is now known as ysandeep | 09:03 | |
*** sshnaidm|afk is now known as sshnaidm | 09:11 | |
openstackgerrit | Merged zuul/zuul-jobs master: yamlint: EOF newlines and comments indent https://review.opendev.org/725516 | 09:27 |
*** bhavikdbavishi has quit IRC | 09:31 | |
*** bhavikdbavishi has joined #zuul | 09:37 | |
*** felixedel has quit IRC | 09:42 | |
*** harrymichal has joined #zuul | 10:05 | |
*** rpittau is now known as rpittau|bbl | 10:18 | |
*** guillaumec has joined #zuul | 10:19 | |
*** root____4 has joined #zuul | 10:32 | |
zbr | avass: does anyone remember the debate about wrapping console vs not-wrapping, here is another example: https://review.rdoproject.org/zuul/build/5f77d48e438a443a8946355c65db89b4/console | 10:34 |
zbr | avass: oops, was not for you in particular. | 10:34 |
zbr | lack of wrapping makes impossible to read the error line | 10:35 |
root____4 | Hello, I would like to ask the maintenance staff of zuul? I encountered a failure when trying to install nodepool-launcher. The error is reported as follows, I tried to manually modify this part of the code, let him automatically create the corresponding path folder. But it has not been resolved. http://paste.openstack.org/show/793574/ | 10:39 |
root____4 | This is the document I checked for installation. https://zuul-ci.org/docs/zuul/howtos/nodepool_install.html?highlight=nodepool | 10:39 |
*** root____4 is now known as ruffian_sheep | 10:40 | |
ruffian_sheep | Do any zuul maintainers or others know how to solve this problem? My nodepool service cannot start normally now. Even if I modified the code to let it create the folder itself. | 10:41 |
*** fbo|afk is now known as fbo | 10:43 | |
ruffian_sheep | clarkb | SpamapS | ianw | corvus | frickler | fungi | jlk | jhesketh | mordred | pabelanger | rcarrillocruz | tobiash | tristanC : are u guys online? | 10:44 |
jhesketh | ruffian_sheep: have you checked the permissions of the /var/run/nodepool folder?\ | 10:47 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-tox-output: use tox_extra_args https://review.opendev.org/728023 | 10:50 |
avass | zbr: I don't think i had a strong enough opinion in that topic, but I think the conclusion was that 'it depends' and I think I agree with that, so I'm not against be able to wrap the output but maybe making it configurable? | 10:51 |
avass | zbr: though, that output looks more like a problem with ANSI characters than not wrapping the line doesn't it? | 10:52 |
avass | zbr: and hmm, not line breaking for \n | 10:52 |
ruffian_sheep | jhesketh :If I creat it, it will be d-wxr ---- t, if I do n’t make changes in code. This folder will not be generated automatically, and it will show as I pasted it, there is no corresponding folder | 10:52 |
avass | zbr: I doubt that would be much easier to read even if it wrapped | 10:53 |
jhesketh | ruffian_sheep: you shouldn't need to modify the code | 10:53 |
jhesketh | ruffian_sheep: have you checked the ownership of the folder and made sure you are running nodepool with the right user who has write access to it? | 10:53 |
avass | jhesketh, ruffian_sheep: I think that might be it | 10:54 |
ruffian_sheep | According to the documentation, I don't need to switch users to nodepool, and the folder / var / run / nodepool does not exist at the beginning. And it won't work until I finish the operation. Is there anything I haven't finished yet? In addition to the operations shown in this link. Can't I start the service yet? | 10:57 |
avass | ruffian_sheep: are you running it with systemd? | 11:00 |
jhesketh | (was about to ask the same thing) | 11:03 |
ruffian_sheep | avass | jhesketh :After I failed to use systemctl start nodepool-launcher, I directly executed the corresponding command: / usr / local / bin / nodepool-launcher found that there is a situation where the folder will not be automatically created. | 11:03 |
frickler | ruffian_sheep: the docs need to be updated, see this code for how we do it in our CI https://opendev.org/zuul/nodepool/src/branch/master/playbooks/nodepool-functional-openstack/run.yaml#L105-L114 | 11:04 |
*** jcapitao is now known as jcapitao_lunch | 11:04 | |
avass | ruffian_sheep, jhesketh: isn't systemd supposed to solve that for you? | 11:05 |
avass | frickler: ^ | 11:06 |
avass | frickler: looking at our build scripts we don't create those | 11:06 |
avass | frickler: but we also run it with systemd :) | 11:06 |
avass | frickler: and you don't so that's probably why | 11:06 |
ruffian_sheep | avass : I don't quite understand what you mean. Can you explain it? | 11:09 |
ruffian_sheep | frickler : I should change the code? | 11:09 |
avass | ruffian_sheep: I believe systemd creates /var/run/nodepool for you. So you shouldn't get that error if you run 'sudo systemctl start nodepool-launcher' | 11:10 |
avass | ruffian_sheep: if you installed the service files | 11:10 |
avass | ruffian_sheep: do you get the same error if you use systemd? | 11:11 |
avass | ruffian_sheep: do you get an error if you run 'nodepool-launcher -d'? that shouldn't require a pidfile so maybe you're getting a different error as well | 11:12 |
frickler | avass: I was referring to the deployment example in the docs, which doesn't use systemd | 11:12 |
avass | frickler: which ones? :) | 11:13 |
ruffian_sheep | I thinkhttp://paste.openstack.org/show/793577/ | 11:13 |
avass | frickler: maybe this needs to be updated with an example how to do it without systemd: https://zuul-ci.org/docs/zuul/howtos/nodepool_install.html?highlight=nodepool#service-file | 11:14 |
ruffian_sheep | avass : yes, Really different | 11:14 |
avass | ruffian_sheep: ah yeah, so systemctl start nodepool is probably crashing with that error | 11:14 |
tobiash | ruffian_sheep: your last paste shows that you have an issue with the nodepool config (the provider references the clodu devstack-admin which probably has no entry in the clouds.yaml) | 11:15 |
ruffian_sheep | avass : My environment does not seem to have the systemd command. It seems that the service can only be started by sudo systemctl start nodepool-launcher | 11:15 |
avass | ruffian_sheep: systemctl is part of systemd :) | 11:16 |
ruffian_sheep | tobiash :I think the last pasted link caused an error due to a problem with this part of my configuration. cloud: devstack-admin # This needs to match the name in clouds.yaml. Does this directly affect the service startup? | 11:19 |
frickler | avass: oh, indeed, I read this wrongly, sorry. but an example to run manually for debugging purposes might be helpful, yes | 11:20 |
ruffian_sheep | avass : may. . . I still don't quite understand the meaning of using systemd operation. | 11:20 |
avass | ruffian_sheep: yes | 11:21 |
zbr | how can I avoid getting a POST_FAILURE with zuul when normal run failed? post runs and is expected to fail in this case | 11:21 |
avass | We had a simlar problem this week with a mispelled profile name for AWS, and that caused nodepool-launcher to not start | 11:21 |
avass | zbr: check 'zuul_success' if it succeeded :) | 11:21 |
zbr | mainly I want to do something like "ignore_errors: if run is failed" kind of behavior. | 11:21 |
zbr | like "ignore_errros: zuul_success is failed" ? | 11:22 |
avass | I've been thinking about pushing a fix to ignore the erroring pool but ahven't gotten around to it yet | 11:22 |
avass | zbr: something like 'when: zuul_success|bool|default(True)' | 11:22 |
avass | zbr: would be better wouldn't it? | 11:23 |
zbr | not really because I still want to run the post, as it may be able to collect some partial output. | 11:23 |
avass | zbr: https://zuul-ci.org/docs/zuul/reference/jobs.html?highlight=zuul_success#var-zuul_success | 11:23 |
avass | zbr: hmm, can you check if the output exists instead then? | 11:23 |
zbr | i only want to ignore errors from POST when build already failed. | 11:23 |
avass | zbr: because ignore_errors can lead to other problems if it fails when it shouldn't | 11:24 |
avass | zbr: but yes you can use ignore_errors | 11:24 |
zbr | not really, because i want to post to fail if run finished succesfully without producting artifacts I expect | 11:24 |
zbr | is a conditional ignore errors | 11:24 |
zbr | thanks, going to try it now. | 11:25 |
avass | zbr: but it should probably be 'ignore_errors: "not {{ zuul_succes|bool }}' :) | 11:26 |
*** ruffian_sheep has quit IRC | 11:27 | |
*** bhavikdbavishi has quit IRC | 11:37 | |
jkt | I wonder why I have to explicitly add other-project into my job's required-projects when that job is only defined in that other-project | 11:47 |
jkt | (and of course it works without required-projects in case this change Depends-on a change from other-project, that one I understand) | 11:48 |
*** lseki has quit IRC | 11:51 | |
avass | jkt: because a job can be defined in any project. that's why we have zuul-jobs for example. :) | 11:51 |
*** rlandy has joined #zuul | 11:53 | |
jkt | avass: so you're essentially saying that it doesn't matter in which project a job is defined. OK, this makes sense, even if I find it a bit surprising | 11:53 |
jkt | I somehow thought that these jobs "linked from config projects" were special | 11:54 |
jkt | now that explains why I cannot define two jobs with the same name in two "leaf" projects :) | 11:54 |
AJaeger | jkt: we have a global namespace for jobs etc. So, everything is shared. That why we have a naming policy to name normal jobs $project-X instead of X - to avoid name collisions | 11:55 |
openstackgerrit | Merged zuul/zuul-jobs master: Combine javascript deployment and deployment-tarball jobs https://review.opendev.org/727370 | 12:02 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: fetch-sphinx-tarball: introduce zuul_use_fetch_output https://review.opendev.org/681870 | 12:03 |
*** jpena is now known as jpena|lunch | 12:07 | |
zbr | avass: not sure why but apparently ignore errors in post does not seem to work, see https://review.rdoproject.org/r/#/c/27547/ | 12:15 |
zbr | i am going to try with true, just too see if condition is wrong | 12:15 |
*** rpittau|bbl is now known as rpittau | 12:15 | |
*** jcapitao_lunch is now known as jcapitao | 12:17 | |
tobiash | zbr: I didn't know that ignore errors on play level is a thing | 12:18 |
tobiash | so far I've only seen that on task level | 12:20 |
*** rfolco|rover has joined #zuul | 12:20 | |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: CLI: Fix errors with the REST client https://review.opendev.org/728061 | 12:21 |
*** saneax has joined #zuul | 12:21 | |
*** saneax has quit IRC | 12:22 | |
*** saneax has joined #zuul | 12:23 | |
*** sanjayu_ has quit IRC | 12:23 | |
*** Goneri has joined #zuul | 12:28 | |
*** sanjayu_ has joined #zuul | 12:30 | |
*** saneax has quit IRC | 12:31 | |
*** saneax has joined #zuul | 12:32 | |
*** bhavikdbavishi has joined #zuul | 12:32 | |
*** sanjayu_ has quit IRC | 12:35 | |
*** saneax has quit IRC | 12:35 | |
*** saneax has joined #zuul | 12:35 | |
zbr | tobiash: yes it is, and is very useful in practice for special kind of playbooks. | 12:37 |
zbr | bad, part, it seems not to work with zuul_return, maybe due to the way the variable is defined, maybe is host fact? | 12:38 |
avass | zbr: maybe it's a ansible version thing? | 12:38 |
zbr | i doubt | 12:39 |
*** lseki has joined #zuul | 12:41 | |
avass | zbr: zuul_success is an extra_var | 12:41 |
*** saneax has quit IRC | 12:41 | |
avass | zbr: so that should work there shouldn't it ? | 12:41 |
zbr | i am doing some more testing, hopefully i will narrow it down. | 12:42 |
avass | zbr: oh, I don't think ignore_errors acts like when, so maybe you're just giving it a string at the moment? | 12:43 |
avass | zbr: so you probably need to template the entire expression | 12:43 |
avass | zbr: Yeah I think that's why, tested it locally | 12:45 |
zbr | avass: right! found it few seconds ago. | 12:45 |
zbr | and funny, now I remember this is not the first time hit this. | 12:45 |
zbr | mainly ansible evaluates it as a string instead of having a behavior like when | 12:46 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: REST API: fix discrepancies between RPC and REST outputs for autohold https://review.opendev.org/728073 | 12:54 |
*** saneax has joined #zuul | 13:00 | |
*** jpena|lunch is now known as jpena | 13:05 | |
*** saneax has quit IRC | 13:07 | |
*** bhavikdbavishi has quit IRC | 13:19 | |
*** bhavikdbavishi has joined #zuul | 13:19 | |
*** harrymichal has quit IRC | 13:20 | |
*** tumble has joined #zuul | 13:26 | |
*** bhavikdbavishi1 has joined #zuul | 13:29 | |
openstackgerrit | Merged x/pbrx master: Retire repository https://review.opendev.org/726462 | 13:29 |
*** bhavikdbavishi has quit IRC | 13:30 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 13:30 | |
*** zxiiro has joined #zuul | 13:31 | |
AJaeger | thanks, mordred. please abandon: https://review.opendev.org/#/q/project:x/pbrx+is:open | 13:32 |
mordred | AJaeger: done! | 13:35 |
mordred | AJaeger: also - I don't see what failed in https://review.opendev.org/#/c/717371/ - do you? | 13:35 |
AJaeger | thanks, mordred | 13:39 |
openstackgerrit | Monty Taylor proposed zuul/zuul-website master: Add blog to website https://review.opendev.org/724648 | 13:40 |
AJaeger | https://zuul.opendev.org/t/zuul/build/35a94ce1bd8447dea37c5431377e1425/log/job-output.txt#566 is the failure | 13:41 |
AJaeger | So, what's wrong in copy-media.yaml ? | 13:41 |
mordred | oh! weird | 13:45 |
mordred | looking | 13:45 |
mordred | AJaeger: tasks is a list | 13:47 |
mordred | not a dict :) | 13:47 |
mordred | AJaeger: although - that said - I think there is a flaw in this | 13:47 |
mordred | I'll push up a fix for this but then we can think about making it better for zuul-website (which is doing something a little weird) | 13:48 |
AJaeger | ah | 13:48 |
openstackgerrit | Monty Taylor proposed zuul/zuul-website master: Switch website to Gatsby https://review.opendev.org/717371 | 13:48 |
mordred | AJaeger: oh - nevrmind, the thing I thought was broken is actually good | 13:49 |
AJaeger | Now I see the problem... | 13:49 |
mordred | the "build javascript tarball" role is a post playbook int he base job, so it'll run _after_ we copy the media in place, so the tarball should be correct | 13:49 |
AJaeger | ah | 13:50 |
mordred | so - I think we still may need to make a publish job for this right? | 13:51 |
mordred | although it was working before | 13:51 |
mordred | AJaeger: it runs opendev-promote-javascript-content - so I think that should work with this having uploaded a tarball right? | 13:52 |
mordred | AJaeger: oh - I need to update the download_artifact_job var | 13:55 |
AJaeger | correct, you need to update that one | 13:55 |
mordred | AJaeger: nod. and actually- that job isn't the right job for this - that's about the tarballl | 13:57 |
*** bhavikdbavishi has quit IRC | 13:57 | |
mordred | AJaeger: I think what I need is to update the job similar to what it was before, but with the "fetch tarball and untar it" step | 13:57 |
mordred | which I think might be another base-jobs job | 13:58 |
* mordred works | 13:58 | |
*** sgw has joined #zuul | 13:58 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-tox-output: use tox_extra_args https://review.opendev.org/728023 | 14:15 |
openstackgerrit | Monty Taylor proposed zuul/zuul-website master: Switch website to Gatsby https://review.opendev.org/717371 | 14:16 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add simple testing for Zuul CLI & REST API https://review.opendev.org/728098 | 14:17 |
fungi | ttx pointed me to this new leboncoin blog post with significant zuul mention, it's a good read: https://medium.com/leboncoin-engineering-blog/leboncoin-commits-life-960a86cd35ff | 14:23 |
corvus | that's pretty slick! :) | 14:27 |
corvus | "We are currently working on automated tests allowing automatic production deployment." i like that :) | 14:29 |
avass | fungi: oh, cool | 14:33 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-tox-output: use tox_extra_args https://review.opendev.org/728023 | 14:37 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-tox-output: use tox_extra_args https://review.opendev.org/728023 | 14:38 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-tox-output: use tox_extra_args https://review.opendev.org/728023 | 14:54 |
*** evrardjp has quit IRC | 14:55 | |
*** evrardjp has joined #zuul | 14:56 | |
openstackgerrit | Merged zuul/zuul-jobs master: tox siblings installed packages: Add PEP 440 direct reference format https://review.opendev.org/727475 | 15:00 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: Add simple testing for Zuul CLI & REST API https://review.opendev.org/728098 | 15:09 |
openstackgerrit | Merged zuul/nodepool master: Update dib to 2.36.0 https://review.opendev.org/723761 | 15:11 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: fetch-tox-output: use tox_extra_args https://review.opendev.org/728023 | 15:23 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: tox: use tox_extra_args, add tox_config_file https://review.opendev.org/728023 | 15:30 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: tox: use tox_extra_args, add tox_config_file https://review.opendev.org/728023 | 15:31 |
*** ysandeep is now known as ysandeep|sleep | 15:31 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: tox: use tox_extra_args, add tox_config_file https://review.opendev.org/728023 | 15:39 |
openstackgerrit | Matthieu Huin proposed zuul/zuul master: REST API: remove useless tenant when doing autohold query by id https://review.opendev.org/728118 | 15:42 |
*** jcapitao is now known as jcapitao_afk | 15:44 | |
AJaeger | corvus: want to approve the ownership policy change at https://review.opendev.org/#/c/724855/ and tristanC's https://review.opendev.org/#/c/681870/ fetch-sphinx-tarball change? Both have two +2s, so I could also +A but wanted to give you a change to review | 15:45 |
corvus | AJaeger: yep, i think we got good sign-offs on the policy on earlier revs | 15:48 |
AJaeger | corvus: agreed | 15:49 |
avass | corvus: we wanted to wait with merging the rest of the stack until next week though, right? | 15:51 |
corvus | avass: yep, i think leaving your WIP vote in place on 727717 until then is good | 15:52 |
avass | hmm, we're using tox so much so I'm almost thinking about creating a tox module for ansible instead of updating and trying to keep the tox jinja consistent everywhere | 15:56 |
avass | that would probably make things much easier | 15:56 |
corvus | AJaeger, tristanC, mordred: was 681870 the one where we were talking about the docs/ and artifacts/ directory under zuul-fetch-output? what was the result of that conversation? | 15:57 |
avass | corvus: there's no way to supply an ansible module with zuul-jobs without a role is there? | 15:59 |
*** bhavikdbavishi has joined #zuul | 16:00 | |
*** rpittau is now known as rpittau|afk | 16:01 | |
tristanC | AJaeger: corvus: mordred: iiuc the current proposal using zuul-output is idendical to what synchronize do. We could use zuul-output/docs but that requires using the merge-zuul-output role, thus i'd like to do that in a follow-up | 16:01 |
AJaeger | corvus: that was the one - and I don't remeber. Happy to remove my +2... | 16:01 |
corvus | avass: no. but symlinks between roles might work. | 16:01 |
avass | corvus: yeah that might be enough | 16:01 |
avass | corvus: how about having a library in the root and symlink to the library for each role? | 16:02 |
avass | corvus: or, just put the tox module in the tox role :) | 16:03 |
corvus | tristanC, AJaeger, mordred: yeah, i just think that the reason we're not using those other directories yet is that it's really hard to change all the synchronize invocations. this seems like the time to do it (or abandon it). basically, if we make a "new system" (ie, fetch-output + merge-output) we should either use it or abandon it. | 16:04 |
openstackgerrit | Merged zuul/zuul-jobs master: Policy rule for ownership between remote and executor https://review.opendev.org/724855 | 16:04 |
corvus | avass: i think either would be fine | 16:04 |
corvus | avass: i'd probably tend toward putting it in tox. seems like a logical place. | 16:04 |
*** bhavikdbavishi1 has joined #zuul | 16:04 | |
avass | corvus: but it would have been nice to be able to supply a module library the same way we can re-use a role in zuul-jobs in a different repo | 16:05 |
corvus | tristanC, AJaeger, mordred: because if we duplicate synchronize to fetch-output, then i don't know how we will migrate from fetch-output-like-synchronize to fetch-output-as-designed | 16:05 |
*** bhavikdbavishi has quit IRC | 16:05 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 16:05 | |
tristanC | corvus: the migration should be transparent at that point | 16:05 |
tristanC | corvus: e.g. once merge-output is mandatory | 16:06 |
corvus | tristanC: i don't know about that -- won't we end up with a patchwork of roles expecting docs in logs, and other ones expecting them in docs.... | 16:06 |
corvus | tristanC: isn't it already, if you want your docs to be in logs? | 16:06 |
tristanC | corvus: right now, `fetch-sphinx-tarball` puts the docs in logs, my proposal with `zuul_use_fetch_output` is to do the same, in a backward compatible way | 16:07 |
corvus | tristanC: right, i'm saying that the fetch-output role is designed differently, and as we use it, we should use it as designed | 16:08 |
corvus | tristanC: or, if we don't want to use it that way, we should change its design to what we want | 16:08 |
tristanC | corvus: i wasn't aware of the merge-zuul-output requirement and we haven't integrate it (our post job doesn't run that job) | 16:09 |
tristanC | role* | 16:09 |
corvus | tristanC: is it problematic to add it? | 16:10 |
corvus | there was a conversation about this from a few days ago, what were the agreed upon outcomes from that?= | 16:11 |
tristanC | corvus: i don't get why we should abandon or enforce the ~/zuul-output/docs` usage. That can be done transparently in a follow-up | 16:11 |
corvus | tristanC: i'm not sure it can | 16:11 |
corvus | tristanC: does anything use zuul-output/docs? have we ever seen that work? | 16:12 |
corvus | is there a docs publication job anywhere that uses that directory? | 16:13 |
corvus | if not, how would we start using it? | 16:13 |
corvus | how could such a job know to use ~work/docs vs ~/work/logs? | 16:13 |
tristanC | corvus: i don't know | 16:14 |
corvus | i don't either, which is why i don't know that we can make this change transparently later. i just want to know what the plan is. | 16:15 |
*** y2kenny has joined #zuul | 16:16 | |
tristanC | corvus: i meant, the current proposal should be transparent, it just make the fetch-sphinx role works with kubectl node, resulting in the same artifacts as the one produced with synchronize | 16:17 |
tristanC | so i guess that if we change that, e.g. make fetch-sphinx produce artifacts in the log directory, then that is already a behavior change | 16:17 |
corvus | tristanC: right, but it uses fetch-output in a way that i don't think fetch-output is expecting. if we're going to use fetch-output we should use it right, or make sure that we're not about to use it in a way that will prevent us from migrating to it correctly. | 16:17 |
corvus | if we're going to put docs in the logs directory instead of the docs directory, then i think we need one of two things: (a) a plan for how we're going to move to using the docs directory in the future; or (b) to abandon use of the docs directory if no one understands how it's supposed to be used. | 16:18 |
corvus | the one thing i don't think we should do is use fetch-output in a way that will prevent us from using it the way we want to use it in the future, and without a plan for (a) i don't know we can say that. | 16:19 |
tristanC | then i vote for (b), it doesn't seems to be used and i don't understand what is the benefit | 16:20 |
tristanC | in the meantime, the sphinx and reno job are simply not working with kubectl node | 16:20 |
*** sshnaidm is now known as sshnaidm|afk | 16:21 | |
corvus | tristanC, mordred: this is your recent conversation: http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2020-05-12.log.html#t2020-05-12T16:27:12 | 16:21 |
corvus | tristanC, mordred: can you discuss that further and come to an agreement on what fetch-output should do? | 16:22 |
corvus | i'm fine with either (a) or (b). | 16:22 |
corvus | tristanC: and whichever of those we do, we can still proceed with http://lists.zuul-ci.org/pipermail/zuul-discuss/2020-April/001215.html | 16:23 |
tristanC | mordred: what is the purpose of using ~/zuul-output/docs/ if the docs is going to be copied over to {{ zuul.executor.log_root }} ? | 16:23 |
corvus | tristanC: (if we move everything to fetch-output, we can just later have fetch-output use the appropriate synchronize module) | 16:23 |
tristanC | understanding the purpose of ~/zuul-output/docs would help figure out a play for (a) | 16:25 |
tristanC | plan* | 16:25 |
mordred | tristanC: the purpose is so that jobs can write docs to be published into a dir on the remote node separately from the log output they publish. the implementation of publishing draft documentation by way of the log publication is an implememntaion detail | 16:25 |
mordred | that way a job can always say "these are the docs I produce" | 16:25 |
tristanC | mordred: so it's just so that we can write ~/zuul-output/docs instead of ~/zuul-output/logs/docs ? | 16:26 |
mordred | then for jobs taht want to publish documentaiton can always just put them into the docs dir - and contextually the underlying system to eitehr put them into the logs dir for preview or into a final location that isn't the log publishing system for publication | 16:26 |
*** dpawlik has quit IRC | 16:27 | |
mordred | tristanC: yes. that said - I'm ok with changing the intent there - but that's the why it was done that way originally - so that the admin of a zuul could define behavior for logs and docs differently | 16:27 |
corvus | it seems like most of our docs publication in opendev has moved to being promote-based, and that only requires a docs archive in the logs dir | 16:28 |
mordred | yeah. I *think* it's ok to do what tristanC is suggesting here - I'm pretty sure our understanding of the world has moved on | 16:28 |
mordred | I'm mostly just trying to make sure I'm sharing as much as I understand about the original whuy | 16:28 |
mordred | why | 16:28 |
corvus | mordred: thanks. that's kind of where i'm ending up too: that artifact-based promote has superceded the idea of specific directories on build nodes | 16:29 |
tristanC | i guess the other quirk is that for multinode jobs, then ~/zuul-output/logs gets published using a hostname prefix dir | 16:29 |
mordred | tristanC: yah - but maybe just don't do docs builds in multinode jobs :) | 16:29 |
corvus | tristanC: oh that's a good point. | 16:30 |
mordred | maybe docs should always go to zuul-output/logs/docs without a hostname prefix in all cases? | 16:30 |
mordred | just in cae someone decides they need a multi-node docs job - or maybe it's a multi-node job that also makes docs or something (like a 5 node C++ build farm that also has a code-doc output) | 16:31 |
tristanC | not sure what would be the expected behavior if a multinode job publish a ~/zuul-output/logs/report.html file, i guess only one will get published so that's not much better anyway | 16:32 |
*** evrardjp has quit IRC | 16:33 | |
corvus | tristanC: if a multinode job did that, it would be published in its hostname subdir | 16:33 |
*** evrardjp has joined #zuul | 16:33 | |
tristanC | i find ~/zuul-output/{docs,logs,artifacts} idea clever, but it is also subtle and it can be confusing when the behavior is different depending on the number of node, thus i would still vote for (b) to make things simpler | 16:34 |
*** guillaumec has quit IRC | 16:34 | |
corvus | tristanC: (b) is to use only zuul-output/logs, but we still have the hostname subdirectory on multinode jobs there | 16:35 |
corvus | (that's like the one part of the fetch-output system that is fully used) | 16:35 |
corvus | using zuul-output/{docs,artifacts} might actually let us work around that problem | 16:36 |
tristanC | corvus: according to https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/fetch-output/tasks/main.yaml#L19 , if all the nodes of a multinode job produces a ~/zuul-output/docs/file , then only the last one will get published as the synchronize dest doesn't use hostname subdirectory prefix for docs | 16:36 |
corvus | tristanC: yes that's documented: https://zuul-ci.org/docs/zuul-jobs/log-roles.html#role-fetch-output | 16:37 |
corvus | i think mordred's use cas of a multinode build job with one docs output is a useful way to think about it | 16:38 |
tristanC | oh, well i find it a confusing behavior then | 16:38 |
corvus | we're not trying to publish multiple docs builds, we're trying to publish one doc build, that just happened to be an output from a multinode job | 16:38 |
tristanC | and in such extrem case of multinode doc building job, wouldn't it be better to explicitely refer to the node hostname to avoid such overwriting issue? | 16:39 |
corvus | that's a reasonable approach | 16:39 |
mordred | ++ | 16:39 |
*** rlandy is now known as rlandy|biab | 16:40 | |
corvus | so it sounds like we're still in favor of b: drop docs/artifacts and the merge-output-to-logs role? | 16:40 |
tristanC | yes, but i can go with (a) if the majority prefer, i don't have a strong opinion | 16:43 |
tristanC | mordred: has the job to publish all the files from the ~/zuul-output/docs ever be written yet? | 16:43 |
mordred | tristanC: I don't see anything that does, no. like corvus said - I think the promote based workflow really superceded this, since doc publication jobs in opendev now fetch the doc tarball and untar it to the correct publication dir | 16:46 |
mordred | I did a search though base-jobs, project-config, ozj and z-j and it doesn't look like anyhting is using this interface on our end | 16:46 |
*** jcapitao_afk is now known as jcapitao | 16:49 | |
corvus | mordred, tristanC, AJaeger: based on that, i +2d with comment on https://review.opendev.org/681870 -- that look right? | 16:49 |
tristanC | corvus: sure, then should i send an advance notification about the removal of ~/zuul-outputs/{docs,artifacts} directory support? | 16:50 |
tristanC | then in the future, we could drop the merge-output-to-logs role and remove the custom docs,artifacts creation and synchronize task | 16:50 |
tristanC | and perhaps makes ~/zuul-output/logs a symlink to ~/zuul-output and synchronize ~/zuul-output directly | 16:51 |
corvus | tristanC: yep i think so -- i think i'd send the plan to zuul-discuss first just to give anyone else a chance to say "wait we're using that" | 16:51 |
corvus | tristanC: i dunno about the last one... it's hard to come back from that if we change our minds :) | 16:52 |
corvus | saying explicitly that you want something to go into the logs seems reasonable | 16:52 |
corvus | so maybe we keep zuul-output/logs and we reserve the ability to have zuul-output/foo in the future, we just don't have anything that uses it right now | 16:53 |
*** jcapitao has quit IRC | 16:53 | |
tristanC | alright, it's also less work to keep it like that | 16:53 |
AJaeger | corvus: go ahead and +A ;) | 16:55 |
*** bhavikdbavishi has quit IRC | 16:58 | |
*** bhavikdbavishi has joined #zuul | 16:59 | |
*** bhavikdbavishi1 has joined #zuul | 17:02 | |
*** bhavikdbavishi has quit IRC | 17:03 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 17:03 | |
* AJaeger just did it | 17:06 | |
AJaeger | anybody else to review an upload-artifactory role, please? https://review.opendev.org/725678 | 17:07 |
corvus | AJaeger, avass: i have one nit on that, which is that we usually have the zuul-tests.d/ file match the docs file. | 17:10 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: Simplify zuul-output usage and remove merge-output-to-logs https://review.opendev.org/728151 | 17:11 |
*** jpena is now known as jpena|off | 17:13 | |
openstackgerrit | James E. Blair proposed zuul/zuul-jobs master: Move artifactory test job https://review.opendev.org/728152 | 17:13 |
avass | corvus: corvus: We do? | 17:13 |
corvus | avass, AJaeger: but we don't need a 54th patchset for that | 17:13 |
avass | :) | 17:13 |
tristanC | corvus: mordred: let me know if i understand the (a) plan correctly in https://review.opendev.org/728151 | 17:13 |
avass | corvus: oh I see | 17:13 |
corvus | avass: yeah, it should be 1:1. at least, it was the last time i touched it :) | 17:14 |
avass | corvus: I don't think it is anymore :) | 17:14 |
corvus | sigh | 17:14 |
avass | corvus: But I could try to clean that up some day | 17:14 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Add a tox module https://review.opendev.org/728154 | 17:14 |
avass | before I get too invested in this, how about something like that ^? | 17:15 |
avass | oh oops | 17:15 |
*** panda is now known as panda|out | 17:15 | |
avass | well you get the point but I need to fix that mess from git | 17:15 |
corvus | avass: after my change, every "zuul-tests.d/foo-roles-jobs.yaml" file corresponds to a "doc/source/foo-roles.rst" file | 17:16 |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Add a tox module https://review.opendev.org/728154 | 17:16 |
avass | corvus: Oh, I thought I had messed that up, looks like I didn't | 17:16 |
corvus | avass: (there are some foo-roles.rst files that don't have foo-roles-jobs.yaml files, but that's probably mostly just roles that don't have tests yet) | 17:17 |
corvus | avass: yeah, i think we're still pretty organized :) | 17:17 |
avass | corvus: anyway, I didn't want to interrupt the discussion earlier, but any thoughts on being able to distribute modules the same way we do with roles in zuul-jobs? | 17:18 |
corvus | avass: what would use those modules? | 17:19 |
corvus | (if not roles in zuul-jobs) | 17:19 |
AJaeger | corvus, tristanC , do we need an announcement for https://review.opendev.org/726463 | 17:19 |
openstackgerrit | Merged zuul/zuul-jobs master: fetch-sphinx-tarball: introduce zuul_use_fetch_output https://review.opendev.org/681870 | 17:19 |
corvus | AJaeger: i don't think it's a zuul project? | 17:19 |
avass | corvus: well, say you want to run tox, but you don't want the entire tox role | 17:20 |
avass | I guess I don't have a concrete example of it :) | 17:20 |
corvus | avass: isn't the point of the tox role just to run tox? | 17:20 |
AJaeger | corvus, tristanC : let me try again: https://review.opendev.org/#/c/728151/1 removes a role, do we need an announcement for it? | 17:21 |
corvus | avass: (that's why we have other roles like ensure-tox which are separate) | 17:21 |
corvus | avass: the idea with zuul-jobs is that roles are small reusable units of work, so it's easy to assemble jobs as lists of roles | 17:21 |
corvus | avass: so if "tox" is doing too much, then that's a problem :) | 17:22 |
avass | hmm, I guess that's true. I can't think of a good reason to do it | 17:23 |
*** bhavikdbavishi has quit IRC | 17:23 | |
openstackgerrit | Merged zuul/zuul-jobs master: Add upload-artifactory role https://review.opendev.org/725678 | 17:26 |
*** yolanda has quit IRC | 17:28 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Add a tox module https://review.opendev.org/728154 | 17:28 |
avass | corvus: thoughts on that then ^ :) | 17:28 |
*** guillaumec has joined #zuul | 17:30 | |
*** bhavikdbavishi has joined #zuul | 17:35 | |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: Fix quickstart gating, Add git name and email to executor https://review.opendev.org/724096 | 17:42 |
*** fbo is now known as fbo|off | 17:48 | |
corvus | avass: structurally it's fine i think, but the ansible/jinja doesn't look that much less complicated -- are you planning on doing stuff that would be more complex in ansible/jinja than it would be in the module? maybe it'll be more clear when i see the new use. | 17:50 |
avass | corvus: to be honest, not really, I just abandoned it because I realized I can't see it solving the problem I wanted to solve originally | 17:54 |
avass | corvus: I'll probably just add more tests to the roles instead :) | 17:55 |
corvus | avass: more tests are always a good investment :) | 17:57 |
avass | I guess it only made the task easier to read compared to the jinja, but I don't think that's worth maintaining in this case | 17:57 |
AJaeger | zuul-jobs-maint, https://review.opendev.org/726836 makes us not fail if testr is not installed - I tend to ignore the fly-by -1 on that one and will +2 now. Anybody else to review? | 18:03 |
AJaeger | and here's a change to empty output dirs - not sure about that one: https://review.opendev.org/727135 | 18:04 |
corvus | i think avass left a good explanation there | 18:04 |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: WIP: Import user tutorials from Software Factory project blog https://review.opendev.org/728193 | 18:05 |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: WIP: Add tutorial tests https://review.opendev.org/728194 | 18:05 |
openstackgerrit | Merged zuul/zuul-jobs master: Move artifactory test job https://review.opendev.org/728152 | 18:05 |
avass | corvus: yeah, I noticed we can't use the tox job directly since we don't use testr | 18:05 |
avass | corvus: and we were leaving logs on static nodes :) | 18:05 |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: WIP: Add tutorial tests https://review.opendev.org/728194 | 18:06 |
avass | corvus: So I added a cleanup to remove things in zuul-output, but making sure they're empty to start with is probably good too | 18:06 |
corvus | clarkb, tobiash, mordred: i found the missing piece for the loading_errors bug thanks to the extra logging we added (we just hit the bug in a change i wrote). it happens when a change that touches the config depends on another change that touches the config and the merge job for the second change completes before the first and these changes are in a tenant which has a standing config error in a different | 18:09 |
corvus | project in the same tenant because that project's config references a config object that is defined in a project that is not part of this tenant (but is part of another tenant) and the other tenant loads without error and is listed before this one. | 18:09 |
AJaeger | corvus, avass, team, I think https://review.opendev.org/#/c/725030 is fine in general (pep8 linting change) but I would rename the regex variable. But I don't think we need https://review.opendev.org/#/c/725100/ - I'm not seeing a use case for that. What's your take? | 18:11 |
*** hashar has joined #zuul | 18:11 | |
corvus | clarkb, tobiash, mordred: to make it concrete: it happens in the zuul opendev tenant because it loads system-config, which is broken in the zuul tenant because the puppet jobs aren't defined. but it's not broken in the 'opendev' tenant, and the opendev tenant is loaded first. that means the config objects are cached. | 18:11 |
AJaeger | corvus: wow! That's quite a condition! | 18:11 |
avass | corvus: wow | 18:11 |
avass | I had to read that a couple of times | 18:12 |
clarkb | avass: I'm still trying to read and parse it :) | 18:12 |
corvus | sorry about that | 18:12 |
AJaeger | mordred: so, want to continue to retire the puppet modules so that we can get rid of that config error ? https://review.opendev.org/#/c/720901/ and friends needs some more work... | 18:13 |
corvus | i have a repro test case; i should be able to finish this up this afternoon | 18:14 |
corvus | but i'm going to break for exercise and lunch first | 18:15 |
avass | AJaeger: well, the first change undoes what tobiash did when he separated the different matchers to avoid warnings, but the second change, which is not yet ready, was supposed to move the matchers out to the config | 18:15 |
avass | AJaeger: because I think it will be impossible to separate a growing number of output formats that are almost the same and at the same time avoid something that might be errors, so I think it should be possible for the user to configure what they want to match or avoid themselves | 18:17 |
avass | s/errors/warnings | 18:17 |
AJaeger | so, you want the user to pass in a new regex to use instead of PEP8_RE ? | 18:23 |
avass | AJaeger: yeah, or a list of them | 18:24 |
avass | AJaeger: or a negative matcher if for some reason they need that | 18:24 |
avass | AJaeger: the regexes feels a lot like configuration and not something that should be hard coded into the module to me :) | 18:26 |
AJaeger | avass: Ok, getting it. what about the following: rename PEP8_RE to LINT_RE in 725030 and then base 725100 on top of it - and thus allow to replace LINT_RE, and then a third change (part of 725100) for the negative matcher? | 18:27 |
avass | AJaeger: yeah sure | 18:28 |
AJaeger | I think each is a good logical step and we can iterate one after the other - and see whether that is acceptable. | 18:28 |
*** rlandy|biab is now known as rlandy | 18:30 | |
openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: tox: update lint regex to not require column https://review.opendev.org/725030 | 18:31 |
avass | AJaeger: I'll update 725100 later :) | 18:32 |
AJaeger | avass: no urgency - thanks. | 18:33 |
* AJaeger reviews later ;) | 18:33 | |
avass | :) | 18:33 |
avass | AJaeger: there's no hurry, it was just a rabbit hole I fell into when wondering why ansible-lint wasn't leaving comments in gerrit :) | 18:34 |
*** bhavikdbavishi has quit IRC | 18:36 | |
AJaeger | Ah! | 18:36 |
tristanC | what is the recommended way to use a template file located in the project src dir? when using zuul.project.src_dir it is failing because the file doesn't exists on the Ansible Controller | 18:45 |
tristanC | should the user try `{{ zuul.executor.src_root }}/{{ zuul.project.canonical_name }}` ? | 18:46 |
avass | tristanC: is the template file in the project but in a role or in a files directory next to the playbook? | 18:49 |
avass | not in a role* | 18:49 |
avass | tristanC: if so I would guess that's the way to do it | 18:50 |
*** dpawlik has joined #zuul | 18:51 | |
tristanC | avass: alright thank you for confirming | 18:53 |
*** felixedel has joined #zuul | 18:53 | |
avass | tristanC: but I don't understand why it wouldn't be in a location easily accessible by ansible :) | 18:54 |
*** felixedel has quit IRC | 19:00 | |
*** nils has quit IRC | 19:20 | |
*** hashar has quit IRC | 19:22 | |
*** hashar has joined #zuul | 19:23 | |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: WIP: Add tutorial tests https://review.opendev.org/728194 | 19:28 |
openstackgerrit | Guillaume Chauvel proposed zuul/nodepool master: Rename quick-start to tutorial https://review.opendev.org/728262 | 19:28 |
tobiash | corvus: awesome finding :) | 19:42 |
*** dpawlik has quit IRC | 19:46 | |
guillaumec | is it possible to change a job's name with multiple changes like I'm trying to do with https://review.opendev.org/#/c/728194/ and https://review.opendev.org/728194 ? | 19:49 |
corvus | guillaumec: you need a 3-step process (copy, switch, delete) | 19:50 |
corvus | i wonder if there's a name for that | 19:51 |
corvus | guillaumec: not sure if you saw earlier, but we were admiring your blog post; very nice! | 19:51 |
guillaumec | corvus: I didn't, which blog post ? | 19:53 |
corvus | guillaumec: oh i'm sorry! i mistook you for a different guillaume C. my apologies; this was the post https://medium.com/leboncoin-engineering-blog/leboncoin-commits-life-960a86cd35ff | 19:55 |
corvus | on the plus side, it's great our community is growing enough we have name collisions :) | 19:56 |
avass | that's an interesting coincidence | 19:56 |
guillaumec | that's not me :) not the same name ! | 19:56 |
corvus | guillaumec: i understand that now, i apologize for my mistake | 19:56 |
avass | corvus: hmm, just noticed that zuul doesn't error if you add a job to a pipeline that doesn't exist | 20:07 |
guillaumec | corvus: my (short) story. I am merely starting to use Zuul, the quick-start tutorial is nice, but having only one change for the check and gate pipelines doesn't show the true power of gating, it even felt redundant. I tried to test gating myself, didn't work because of a strange merge error even if I had made sure it could not happen (patch pending: https://review.opendev.org/#/c/724096/) . Then I found | 20:08 |
guillaumec | softwarefactory-project tutorials which are nice, tristanC pointed me that a change was initiated to port those to zuul documentation. | 20:08 |
corvus | guillaumec: i agree that a great next step after the quick-start is to teach people how to set up gating. thanks for working on that :) | 20:09 |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: WIP: Add tutorial tests https://review.opendev.org/728194 | 20:12 |
avass | \o/ we're now automatically deploying our zuul and nodepool configuration | 20:14 |
guillaumec | corvus: thanks for the blog post nonetheless, I had seen an article about leboncoin using zuul, this one is also nice. I really like Zuul and will try to have it adopt by my company. | 20:17 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Fix loading_errors bug https://review.opendev.org/728286 | 20:32 |
corvus | tobiash, mordred, clarkb: ^ hopefully that's more clear :) | 20:32 |
corvus | as expected, it's a one-line fix with 71 lines of testing :) | 20:33 |
avass | :) | 20:34 |
clarkb | corvus: added to my review queue. I think that is change ~6 | 20:35 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Fix loading_errors bug https://review.opendev.org/728286 | 20:37 |
corvus | pep8 ^ | 20:37 |
*** hashar has quit IRC | 20:49 | |
clarkb | corvus: commented. I think therre is a small update that would be good to have to avoid future confusion (and then a second minor nit thing) | 20:54 |
openstackgerrit | James E. Blair proposed zuul/zuul master: Fix loading_errors bug https://review.opendev.org/728286 | 20:58 |
corvus | clarkb: thanks fixed | 20:59 |
clarkb | lgtm thanks | 20:59 |
*** Goneri has quit IRC | 21:04 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Fix loading_errors bug https://review.opendev.org/728286 | 21:05 |
corvus | clarkb: oops, one more thing ^ i forgot to remove my extra debugging | 21:05 |
openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: WIP: Add tutorial tests https://review.opendev.org/728194 | 21:42 |
*** mattw4 has joined #zuul | 22:35 | |
*** mattw4 has quit IRC | 23:03 | |
*** tosky has quit IRC | 23:05 | |
*** tumble has quit IRC | 23:15 | |
*** jamesmcarthur has joined #zuul | 23:29 | |
*** jamesmcarthur has quit IRC | 23:39 | |
*** jamesmcarthur has joined #zuul | 23:44 | |
*** jamesmcarthur has quit IRC | 23:46 | |
*** guillaumec has quit IRC | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!