| *** cdearborn has quit IRC | 00:28 | |
| *** jamesmcarthur has joined #zuul | 01:01 | |
| *** ysandeep|away is now known as ysandeep | 01:03 | |
| ianw | i feel like a builder-only nodepool configuration doesn't actually need labels: ? only the launchers? | 01:12 |
|---|---|---|
| *** swest has quit IRC | 01:15 | |
| clarkb | ianw: I think we only build imagesif nodepool sees labels use them | 01:18 |
| clarkb | which us why we have that stub like config there | 01:18 |
| ianw | hrm, i wonder if the config validator should ensure diskimages have labels then | 01:19 |
| ianw | | centos-8-arm64-0000000001 | centos-8-arm64 | nb03 | qcow2 | ready | 00:00:16:31 | | 01:20 |
| *** jamesmcarthur has quit IRC | 01:24 | |
| *** swest has joined #zuul | 01:32 | |
| *** sugaar has quit IRC | 01:55 | |
| *** sugaar has joined #zuul | 01:56 | |
| *** Goneri has quit IRC | 01:59 | |
| *** Pilou has joined #zuul | 02:07 | |
| *** ysandeep is now known as ysandeep|afk | 02:21 | |
| openstackgerrit | Merged zuul/zuul-jobs master: fetch-subunit-output test: use ensure-pip https://review.opendev.org/718225 | 02:42 |
| *** igordc has joined #zuul | 02:46 | |
| *** igordc has quit IRC | 02:52 | |
| *** igordc has joined #zuul | 02:52 | |
| openstackgerrit | Merged zuul/zuul-jobs master: ensure-tox: use ensure-pip role https://review.opendev.org/717663 | 02:55 |
| *** igordc has quit IRC | 02:57 | |
| *** jamesmcarthur has joined #zuul | 03:24 | |
| *** bhavikdbavishi has joined #zuul | 03:25 | |
| *** bhavikdbavishi1 has joined #zuul | 03:28 | |
| *** bhavikdbavishi has quit IRC | 03:30 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 03:30 | |
| *** ysandeep|afk is now known as ysandeep | 04:22 | |
| *** evrardjp has quit IRC | 04:37 | |
| *** evrardjp has joined #zuul | 04:37 | |
| *** ysandeep is now known as ysandeep|reboot | 04:49 | |
| openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: Update Fedora to 31 https://review.opendev.org/717657 | 04:51 |
| openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: Make ubuntu-plain jobs voting https://review.opendev.org/719701 | 04:51 |
| openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: Document output variables https://review.opendev.org/719704 | 04:51 |
| openstackgerrit | Ian Wienand proposed zuul/zuul-jobs master: Python roles: misc doc updates https://review.opendev.org/720111 | 04:51 |
| *** ysandeep|reboot is now known as ysandeep | 04:53 | |
| *** swest has quit IRC | 05:00 | |
| *** swest has joined #zuul | 05:00 | |
| *** zxiiro has quit IRC | 05:10 | |
| *** mnasiadka has quit IRC | 05:10 | |
| *** adam_g has quit IRC | 05:10 | |
| *** zxiiro has joined #zuul | 05:15 | |
| *** mnasiadka has joined #zuul | 05:15 | |
| *** adam_g has joined #zuul | 05:15 | |
| *** jamesmcarthur has quit IRC | 05:30 | |
| *** jamesmcarthur has joined #zuul | 05:30 | |
| *** sgw has quit IRC | 05:41 | |
| *** ysandeep is now known as ysandeep|brb | 05:49 | |
| *** jamesmcarthur has quit IRC | 05:53 | |
| *** ysandeep|brb is now known as ysandeep | 06:12 | |
| *** zxiiro has quit IRC | 06:16 | |
| *** jamesmcarthur has joined #zuul | 06:43 | |
| *** jamesmcarthur has quit IRC | 06:47 | |
| *** jamesmcarthur has joined #zuul | 06:55 | |
| *** yolanda has quit IRC | 06:59 | |
| *** jamesmcarthur has quit IRC | 06:59 | |
| *** yolanda has joined #zuul | 07:00 | |
| *** jamesmcarthur has joined #zuul | 07:01 | |
| *** jhesketh has quit IRC | 07:04 | |
| *** jamesmcarthur has quit IRC | 07:05 | |
| *** jamesmcarthur has joined #zuul | 07:07 | |
| *** harrymichal has joined #zuul | 07:10 | |
| *** jamesmcarthur has quit IRC | 07:11 | |
| *** jamesmcarthur has joined #zuul | 07:13 | |
| *** jcapitao has joined #zuul | 07:16 | |
| *** jamesmcarthur has quit IRC | 07:17 | |
| *** jamesmcarthur has joined #zuul | 07:19 | |
| *** rpittau|afk is now known as rpittau | 07:19 | |
| *** jpena|off is now known as jpena | 07:22 | |
| *** jamesmcarthur has quit IRC | 07:23 | |
| *** tosky has joined #zuul | 07:30 | |
| *** bhavikdbavishi has quit IRC | 07:34 | |
| *** jamesmcarthur has joined #zuul | 07:46 | |
| *** jamesmcarthur has quit IRC | 07:46 | |
| *** jamesmcarthur has joined #zuul | 07:46 | |
| *** jamesmcarthur has quit IRC | 07:49 | |
| *** jamesmcarthur has joined #zuul | 07:49 | |
| *** threestrands has quit IRC | 07:56 | |
| *** jamesmcarthur has quit IRC | 07:57 | |
| *** ysandeep is now known as ysandeep|lunch | 07:57 | |
| *** ysandeep|lunch is now known as ysandeep | 08:25 | |
| *** jamesmcarthur has joined #zuul | 08:28 | |
| openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Make ubuntu-plain jobs voting https://review.opendev.org/719701 | 08:45 |
| openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Document output variables https://review.opendev.org/719704 | 08:45 |
| openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Python roles: misc doc updates https://review.opendev.org/720111 | 08:45 |
| *** bhavikdbavishi has joined #zuul | 09:09 | |
| *** ysandeep is now known as ysandeep|afk | 09:21 | |
| *** yolanda has quit IRC | 09:23 | |
| *** yolanda has joined #zuul | 09:29 | |
| *** jamesmcarthur has quit IRC | 09:34 | |
| zbr | what is the correct way to detect zuul presence from ansible? | 09:44 |
| zbr | i used "zuul_work_dir is not defined" but apparently it is not reliable enough. | 09:45 |
| *** jamesmcarthur has joined #zuul | 10:03 | |
| *** bhavikdbavishi1 has joined #zuul | 10:08 | |
| *** bhavikdbavishi has quit IRC | 10:08 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 10:08 | |
| *** yolanda has quit IRC | 10:10 | |
| avass | zbr: I guess you can check the zuul dict: https://zuul-ci.org/docs/zuul/reference/jobs.html#zuul-variables | 10:12 |
| zbr | avass: yep, i dediced to check for presence of zuul dict. if someone defines it I can go deeper :D | 10:12 |
| avass | zbr: otherwise I don't know if there's a better way to do it :) | 10:13 |
| zbr | is fine, the previous attempt was wrong because it was using the outcome from a role | 10:13 |
| *** bhavikdbavishi1 has joined #zuul | 10:24 | |
| *** bhavikdbavishi has quit IRC | 10:26 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 10:26 | |
| *** rpittau is now known as rpittau|bbl | 10:30 | |
| *** bhavikdbavishi has quit IRC | 10:34 | |
| *** bhavikdbavishi has joined #zuul | 10:34 | |
| *** bhavikdbavishi has quit IRC | 10:39 | |
| *** bhavikdbavishi has joined #zuul | 10:44 | |
| *** bhavikdbavishi has quit IRC | 10:48 | |
| *** bhavikdbavishi has joined #zuul | 10:51 | |
| *** bhavikdbavishi has quit IRC | 10:57 | |
| *** jcapitao is now known as jcapitao_lunch | 11:05 | |
| tobiash | yeah, I think checking for zuul or maybe even zuul.project is the safest thing | 11:16 |
| avass | tobiash: I guess you can do a duck test by checking zuul.project, zuul.build, zuul.buildset, zuul.executor_work root etc and their content would make it robust enough :) | 11:19 |
| *** jpena is now known as jpena|lunch | 11:37 | |
| *** hashar has joined #zuul | 11:43 | |
| *** rfolco has joined #zuul | 11:47 | |
| *** rlandy has joined #zuul | 12:06 | |
| *** rpittau|bbl is now known as rpittau | 12:19 | |
| *** jcapitao_lunch is now known as jcapitao | 12:22 | |
| *** ysandeep|afk is now known as ysandeep | 12:35 | |
| openstackgerrit | Simon Westphahl proposed zuul/zuul master: Keep task stdout/stderr separate in result object https://review.opendev.org/650276 | 12:40 |
| *** Goneri has joined #zuul | 12:41 | |
| *** jpena|lunch is now known as jpena | 12:44 | |
| jkt | an interesting thing with artifacts: https://gerrit.cesnet.cz/c/CzechLight/netconf-cli/+/2449/4#message-19bab471d8890a29f16a004ecedf3f1798c2f0c2 | 13:00 |
| jkt | there's a parent commit, its build failed because of some transient race in our tests, yet for this item this "lack of artifacts" from the previous change resulted in cancelation of this job | 13:02 |
| jkt | even though the same artifacts are provided by other jobs for *this* change | 13:02 |
| jkt | I wonder if it's possible to tell zuul "hey, please only take this artifact from jobs queued for the current item, not from its parent changes" | 13:03 |
| *** harrymichal has quit IRC | 13:15 | |
| *** cdearborn has joined #zuul | 13:39 | |
| openstackgerrit | Simon Westphahl proposed zuul/zuul master: Keep task stdout/stderr separate in result object https://review.opendev.org/650276 | 13:54 |
| *** ysandeep is now known as ysandeep|away | 14:31 | |
| *** tjgresha_ has joined #zuul | 14:46 | |
| *** jamesmcarthur has quit IRC | 14:47 | |
| *** jamesmcarthur has joined #zuul | 14:47 | |
| *** tjgresha has quit IRC | 14:49 | |
| *** tjgresha__ has joined #zuul | 15:15 | |
| *** tjgresha_ has quit IRC | 15:18 | |
| *** harrymichal has joined #zuul | 15:26 | |
| *** harrymichal has quit IRC | 15:26 | |
| *** harrymichal has joined #zuul | 15:27 | |
| *** saneax has quit IRC | 15:39 | |
| *** dpawlik has quit IRC | 15:50 | |
| *** armstrongs has joined #zuul | 15:56 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add support for custom container image name https://review.opendev.org/720762 | 15:58 |
| *** jamesmcarthur has quit IRC | 15:58 | |
| *** jamesmcarthur has joined #zuul | 15:59 | |
| *** dustinc has joined #zuul | 16:01 | |
| corvus | zbr: in opendev, we generally avoid switching on whether zuul is present. our goal is to run tests the same way in or out of zuul. | 16:03 |
| clarkb | jkt: I think that would violate existing zuul behavior. Basically zuul is always trying to test the future proposed outcome | 16:04 |
| clarkb | jkt: if you dropped an intermediate state you'd be half testing that outcome at best | 16:04 |
| corvus | jkt, clarkb: we're still trying to find the best practice there though -- because if the issue is that change A built the project, and change B depends on A, but *also* built the project, then B doesn't *really* depend on the artifact from A. that's why in the nodepool, zuul, and system-config projects we've been experimenting with more fine-grained provides/requires | 16:05 |
| corvus | i think there's still probably something more to be done in zuul to handle this | 16:06 |
| *** y2kenny has joined #zuul | 16:12 | |
| *** jcapitao has quit IRC | 16:14 | |
| *** rpittau is now known as rpittau|afk | 16:17 | |
| y2kenny | I just want to double check... zuul configs are speculatively run for untrusted-projects but not for config-projects, is that true? | 16:19 |
| y2kenny | Is this due to the privleged nature of config-projects? | 16:20 |
| clarkb | y2kenny: yes and yes | 16:22 |
| y2kenny | clarkb: thanks for confirming. Does the post-review property over ride this behaviour or can this not be override at all? (I am wondering if I can setup a trigger such that trusted user can trigger the speculative run) | 16:25 |
| y2kenny | (on the config-project change) | 16:25 |
| clarkb | y2kenny: post review should override it iirc | 16:26 |
| clarkb | there might be some aspects that still won't but for things like secrets and playbook content I think it would work fine that way | 16:26 |
| y2kenny | um... ok. I should probably describe the context a bit just to explain why I am going down this path. | 16:29 |
| *** ianychoi_ has joined #zuul | 16:29 | |
| y2kenny | I am looking at this because most of the projects won't be zuul native so I will need to have a separate project to store zuul job/project definitions. In order for the side definitions to trigger off the non-zuul-native project, I will have to make it a config-project. | 16:31 |
| y2kenny | But at the same time, I am writing a tutorial for the developer to build their own jobs/projects in this config-project, so it would be good to be able to speculatively run these changes (especially when the team is still learning about zuul) | 16:31 |
| *** ianychoi has quit IRC | 16:31 | |
| y2kenny | this is why I am looking to have speculatively run on a config-project. Down the line I might tighten it such that the speulative run only trigger if trusted user comment !recheck or something in the change comment. | 16:31 |
| *** webknjaz has quit IRC | 16:33 | |
| *** webknjaz has joined #zuul | 16:33 | |
| *** evrardjp has quit IRC | 16:37 | |
| *** evrardjp has joined #zuul | 16:37 | |
| clarkb | y2kenny: I'll need to think about that more | 16:38 |
| y2kenny | clarkb: actually... now that I gave it some more thought... I think I can improve this by splitting the projects and job configs. Essentially just following what you guys are doing for the openstack (i didn't know why you guys did it that way but may be this is why.) | 16:40 |
| y2kenny | so I can have a untrusted-project for the jobs so people can speculatively define the jobs. And an config-projects that would include the 'non-zuul-native' project but consume the job from the untrusted project. That should work right? | 16:42 |
| clarkb | yes | 16:43 |
| y2kenny | so essentially devs can just iterate in the untrusted jobs project (using required-project to bring in the non-zuul-native project(s)) | 16:43 |
| y2kenny | when they are done, add the job to a project definition in the config-project for triggering on changes from the non-native project | 16:44 |
| *** y2kenny has quit IRC | 16:44 | |
| *** y2kenny has joined #zuul | 16:46 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Add support for global image prefix https://review.opendev.org/720780 | 16:51 |
| *** igordc has joined #zuul | 17:04 | |
| fungi | y2kenny: that's precisely why we do it that way in fact | 17:08 |
| fungi | we try to limit what we put into trusted config repos as much as possible because changes to them can't be exercised speculatively | 17:08 |
| *** igordc has quit IRC | 17:09 | |
| fungi | if something can safely go in an untrusted repo, then we try to put it in one | 17:09 |
| *** harrymichal has quit IRC | 17:12 | |
| *** hashar has quit IRC | 17:18 | |
| *** jpena is now known as jpena|off | 17:40 | |
| *** bhavikdbavishi has joined #zuul | 17:42 | |
| y2kenny | fungi: thanks for confirming. I was wondering about the setup but didn't realize it until I ran into the problem myself. | 17:45 |
| *** bhavikdbavishi1 has joined #zuul | 17:52 | |
| *** bhavikdbavishi has quit IRC | 17:54 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 17:54 | |
| *** bhavikdbavishi has quit IRC | 17:58 | |
| *** bhavikdbavishi has joined #zuul | 17:58 | |
| *** y2kenny has quit IRC | 17:59 | |
| *** jamesmcarthur has quit IRC | 18:07 | |
| *** jamesmcarthur has joined #zuul | 18:08 | |
| *** jamesmcarthur has quit IRC | 18:13 | |
| *** harrymichal has joined #zuul | 18:27 | |
| *** harrymichal has quit IRC | 18:41 | |
| *** harrymichal has joined #zuul | 18:41 | |
| *** jamesmcarthur has joined #zuul | 18:42 | |
| *** harrymichal has quit IRC | 18:53 | |
| *** jamesmcarthur has quit IRC | 19:00 | |
| *** jamesmcarthur has joined #zuul | 19:01 | |
| *** bhavikdbavishi has quit IRC | 19:07 | |
| *** jamesmcarthur has quit IRC | 19:15 | |
| *** bhavikdbavishi has joined #zuul | 19:20 | |
| openstackgerrit | Tristan Cacqueray proposed zuul/zuul-operator master: Refactor ZooKeeper service configuration https://review.opendev.org/720822 | 19:53 |
| *** jamesmcarthur has joined #zuul | 20:02 | |
| *** dustinc has quit IRC | 20:29 | |
| *** bhavikdbavishi has quit IRC | 20:35 | |
| *** rfolco has quit IRC | 21:11 | |
| *** hashar has joined #zuul | 21:20 | |
| *** hashar has quit IRC | 21:46 | |
| *** jamesmcarthur has quit IRC | 21:47 | |
| jkt | clarkb, corvus: this was with coverage jobs (where I have a build-this-version job and a build-previous-version job and a generate-coverage-diff job), the are provided and configured in the same project | 22:15 |
| jkt | clarkb: how is that dropping intermediate state? | 22:17 |
| clarkb | jkt: in the coverage case you wouldn't be considering the coverage delta produced by the intermediate change | 22:17 |
| clarkb | jkt: if the goal is to ensure that coverage always increases then that could break | 22:17 |
| jkt | it's late here so I might be dumber than usual, but I really don't follow | 22:18 |
| jkt | I understand that one can use artifacts for a lot of purposes :) | 22:18 |
| jkt | but here I'm not really intending to be passing any state between gerrit changes | 22:19 |
| clarkb | jkt: it was my understanding that you were trying to compare coverage artifacts from the previous changes to ensure that the current change tests/covers what was updated | 22:19 |
| clarkb | in that case you are probably fine | 22:19 |
| clarkb | another coverage related thing that comes up is ensuring coverage doesn't regress ( I personally think that isn't a great practice) and this would break without intermediate results potentially | 22:19 |
| jkt | yeah, but consider a change that's just a gerrit change whose parent in tip of the target branch | 22:20 |
| jkt | there's no parent change | 22:20 |
| jkt | what artifacts would you use? | 22:20 |
| jkt | therefore I have an extra job which is essentially doing a `git reset --hard origin/{{ zuul.branch }}` in its pre-run | 22:21 |
| clarkb | jkt: you'd use the most recent published artifact from the promote queue | 22:21 |
| clarkb | and if that doesn't exist then you assume you are first I guess | 22:21 |
| jkt | that would require a registry of artifacts, similarly to what opendev/openstack is doing with their docker registry I guess | 22:22 |
| jkt | and also gating, which we do not do | 22:22 |
| jkt | (see that mail to the zuul ML I wrote this Monday I think, it has links to working roles and playbooks) | 22:22 |
| jkt | but anyway, that part works, that's not a problem | 22:22 |
| jkt | the unexpected behavior I brought up today is that I have my pipelines configured with fail-fast: True, and a transient failure of build-this-version job in change 1 led to a failure of compare-coverage in change 2 becase compare-coverage need current-coverage artifact | 22:27 |
| jkt | and Zuul apparently infers that if a job requires an artifact that's provided by several "instances" of some jobs in a queue, then all of these jobs must succeed | 22:28 |
| *** igordc has joined #zuul | 23:08 | |
| *** rlandy has quit IRC | 23:13 | |
| *** tosky has quit IRC | 23:21 | |
| *** igordc has quit IRC | 23:27 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!