| opendevreview | Merged zuul/zuul master: Several merger cleanups https://review.opendev.org/c/zuul/zuul/+/805309 | 00:37 |
|---|---|---|
| opendevreview | Merged zuul/zuul master: Cleanup stale locks in merger/executor API https://review.opendev.org/c/zuul/zuul/+/805312 | 00:41 |
| opendevreview | Ian Wienand proposed zuul/zuul master: web: Nodes: use composable table https://review.opendev.org/c/zuul/zuul/+/805338 | 06:24 |
| opendevreview | Ian Wienand proposed zuul/zuul master: [dnm] expand everything example for TreeView https://review.opendev.org/c/zuul/zuul/+/805340 | 06:35 |
| *** rpittau|afk is now known as rpittau | 07:38 | |
| *** jpena|off is now known as jpena | 07:38 | |
| opendevreview | Simon Westphahl proposed zuul/zuul master: Fix wrong varible use when updating resource stats https://review.opendev.org/c/zuul/zuul/+/805361 | 09:39 |
| swest | corvus: ^ small bug we found related to lock/unlock nodes on executor | 09:56 |
| opendevreview | Sorin Sbârnea proposed zuul/zuul-jobs master: Include podman installation with molecule https://review.opendev.org/c/zuul/zuul-jobs/+/803471 | 11:08 |
| *** dviroel|ruck|out is now known as dviroel|ruck | 11:26 | |
| *** bhagyashris_ is now known as bhagyashris | 11:31 | |
| *** jpena is now known as jpena|lunch | 11:36 | |
| *** jpena|lunch is now known as jpena | 12:36 | |
| * AtitPatel[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/LLXdECjbEBFaSneRmyTHVtJA/message.txt > | 12:40 | |
| * AtitPatel[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/XJQdIAPwnZUjghzorsiUYKEQ/message.txt > | 12:40 | |
| AtitPatel[m] | Would someone be able to help me out with finding and fixing the cause please? | 12:40 |
| * AtitPatel[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/hIEoZGtimDOkakAmqLMJAvSl/message.txt > | 12:41 | |
| tobiash[m] | the target ref must be 'refs/for/master' instead of 'refs/changes/03/759003/13' | 12:43 |
| tobiash[m] | @atit | 12:44 |
| tobiash[m] | however it's usually easier to use the git-review tool instead | 12:44 |
| AtitPatel[m] | Dumb alert: | 12:46 |
| AtitPatel[m] | I have never used the tool. | 12:46 |
| AtitPatel[m] | `brew install git-review` I assume? | 12:46 |
| AtitPatel[m] | I think I found the way. | 12:47 |
| AtitPatel[m] | Let me try git-review and I will get back to you in a bit 🙂 Thanks a lot ! | 12:47 |
| tobiash[m] | yes, that tool :) | 12:48 |
| opendevreview | Atit Patel proposed zuul/zuul master: CDEC-27: changes in time out logic, addition of retry to handle slower API responses https://review.opendev.org/c/zuul/zuul/+/805378 | 12:54 |
| mordred | wow. it's in homebrew. TIL | 12:55 |
| AtitPatel[m] | Well, I guess it worked ! tobiash 🙂 | 13:04 |
| AtitPatel[m] | Thanks again for your help. | 13:04 |
| tobiash[m] | no problem :) | 13:05 |
| *** rpittau is now known as rpittau|afk | 13:55 | |
| nirmoy | How does zuul makes sure {{zuul}} variable available in all the hosts/jobs ? I am asking this because I am trying to pass a dict of {'project_name': 'git_hash_of_head'} from a base job to all the final build jobs. I am using set_fact to create the dict in pre-run job of that base job, for some reason the dict isn't available to the final build job. What am I missing ? | 14:16 |
| fungi | nirmoy: if you want to pass information between different builds you need to use zuul-return. if you just want to make facts available to later playbooks in the same build then setting the fact as cacheable should accomplish that | 14:21 |
| fungi | nirmoy: er, sorry, it's zuul_return (underscore not hyphen): https://zuul-ci.org/docs/zuul/reference/jobs.html#return-values | 14:24 |
| corvus | tobiash, swest: quick question on 805361 | 14:32 |
| nirmoy | fungi: I am trying to make facts available to a later playbook in the same build. What do you mean by cacheable fact? | 14:36 |
| corvus | nirmoy: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/set_fact_module.html#synopsis | 14:37 |
| fungi | nirmoy: if you set a fact "cacheable" when you define it, the zuul executor will make it available in subsequent playbooks | 14:37 |
| corvus | well, ansible will do that | 14:37 |
| fungi | fair, the ansible running on the executor | 14:38 |
| nirmoy | corvus,fungi: ah great, thanks for your time :) | 14:38 |
| Clark[m] | Isn't the git hash of head implicitly available in the git repos zuul sets up? | 14:43 |
| opendevreview | Atit Patel proposed zuul/zuul master: CDEC-27: changes in time out logic, addition of retry to handle slower API responses https://review.opendev.org/c/zuul/zuul/+/805396 | 14:43 |
| opendevreview | James E. Blair proposed zuul/zuul master: Fix wrong varible use when updating resource stats https://review.opendev.org/c/zuul/zuul/+/805361 | 14:46 |
| corvus | swest, tobiash: ^ i didn't see that the test change actually validated the fix, so that's an update to do that. | 14:46 |
| corvus | clarkb: any chance you want to take a quick look at that and maybe we can get one more bugfix in before the restart? :) | 14:48 |
| opendevreview | Atit Patel proposed zuul/zuul master: Update bitbucketcloudconnection.py https://review.opendev.org/c/zuul/zuul/+/805399 | 14:48 |
| Clark[m] | corvus: yup let me migrate to the office now that I have tea | 14:49 |
| nirmoy | Clark[m]: git has of head isn't available for jobs trigger by timer pipeline | 14:51 |
| nirmoy | s/has/hash | 14:51 |
| clarkb | nirmoy: it should be in the actual git repo in the job | 14:52 |
| corvus | nirmoy: https://zuul-ci.org/docs/zuul/reference/jobs.html#git-repositories has some info | 14:54 |
| nirmoy | clarkb: I am trying to make that available to bunch of timer pipeline jobs so that I don't have to to keep the same code in all the build jobs | 14:54 |
| clarkb | corvus: I've approved it | 14:55 |
| fungi | though if it's a lightweight job with no separate remote node, i wonder what options you have to actually read the commit id with playbooks from an untrusted repo (if it's a playbook in a config repo or running on a remote node the repository has been pushed to, you can of course just run git show-ref or similar) | 14:55 |
| corvus | fungi: i'm unsure off the top of my head, but there's a possibility the ansible git module could be used to read that data on the executor | 14:56 |
| corvus | no guarantees; just an avenue to explore | 14:56 |
| fungi | right, i wondered if there might be something in ansible which doesn't rely on a blocked lookup | 14:57 |
| opendevreview | Sorin Sbârnea proposed zuul/zuul-jobs master: Include podman installation with molecule https://review.opendev.org/c/zuul/zuul-jobs/+/803471 | 14:59 |
| swest | corvus: the stats assertions that you added are fine, but they are not really validating that the autohold executed w/o exception either | 15:00 |
| swest | the only way to know if the autohold was processed without exception is checking the build.hold flag | 15:01 |
| corvus | swest: yes, but the test already did that | 15:01 |
| clarkb | yup I think the test was previously checking that it ran without exception but not taht the reported data is correct. Now the test does both things | 15:01 |
| corvus | swest: my confusion is that the commit message said (and the actual code change was about) "updating the nodepool resource stats" but we never checked the nodepool resource stats. | 15:02 |
| swest | yeah, but the same stats are also emitted when using the nodeset, so you can't really determine that they came from the autohold loop if I'm not mistaken | 15:02 |
| swest | I was looking for a better way to assert that, but checking the stats isn't enough for that | 15:03 |
| swest | unless I did something completely wrong, which might be entirely possible :) | 15:04 |
| corvus | hrm | 15:05 |
| swest | I didn't want to create the impression that those stats are actually validating the autohold stats | 15:05 |
| swest | should have added a comment 'bout this in the commit message | 15:06 |
| corvus | maybe we can isolate those resources to the held node | 15:07 |
| corvus | swest: basically, i'm looking for a test that will fail without the code change | 15:09 |
| corvus | swest: if we localize the resources so they only attach to the node for change B, then we should get an emission of 1024, followed by 0. and without your fix, we only get 1024. | 15:11 |
| corvus | so i think if we check for that we'll have validated it (and that makes sense -- the change was fixing a "leak" in resource counting, so 1024 -> 0 is expected. | 15:12 |
| corvus | i'm working on an update | 15:14 |
| clarkb | do you want me to remove my +A? | 15:15 |
| corvus | clarkb: let's do this one as a followup | 15:18 |
| corvus | it's not trivial | 15:18 |
| clarkb | ok | 15:18 |
| corvus | swest: i'm confused about your assertion that we have to check the build object to know if it was held -- the existing test already checked that nodepool considered it held | 15:38 |
| zbr | clarkb: can you help give a hand with https://review.opendev.org/c/zuul/zuul-jobs/+/803471 ? | 15:39 |
| opendevreview | James E. Blair proposed zuul/zuul master: Adjust test_autohold to catch stats errors https://review.opendev.org/c/zuul/zuul/+/805416 | 15:48 |
| corvus | clarkb, swest, tobiash: ^ that fails without swest's code fix | 15:48 |
| *** jpena is now known as jpena|off | 15:51 | |
| clarkb | corvus: why remove the build.held check? Isn't that a useful state assertion? | 15:52 |
| corvus | clarkb: i think it duplicates the lines that immediately follow | 15:53 |
| clarkb | oh I guess we check for the held node after that removed build check | 15:53 |
| clarkb | ya | 15:53 |
| corvus | we could do it, but it's complex to get that object, and it seems to me that verifying that nodepool thinks it's held is the most important and is sufficient | 15:54 |
| swest | corvus: the held flag on the build wasn't set because if the exception. That's why I used it to verify the fix. | 15:55 |
| corvus | okay, i'll look at adding it back since it tests a code path... but if there was an exception emitting stats, then we're missing an exception handler | 15:56 |
| corvus | i didn't know there was an exception, i just thought the numbers were wrong | 15:56 |
| corvus | on second thought, looking at that code, i think maybe it's okay to leave that exception unhandled | 15:57 |
| corvus | it's not an exception emitting stats, it's an exception maintaining an internal data structure which needs to be kept in sync | 15:58 |
| opendevreview | Sorin Sbârnea proposed zuul/zuul-jobs master: ensure-docker: enable centos-8-stream testing https://review.opendev.org/c/zuul/zuul-jobs/+/805432 | 16:06 |
| opendevreview | James E. Blair proposed zuul/zuul master: Adjust test_autohold to catch stats errors https://review.opendev.org/c/zuul/zuul/+/805416 | 16:07 |
| corvus | clarkb, swest: okay that adds back in the .held check | 16:07 |
| corvus | i think it's technically redundant at this point, but it has the capability of detecting more errors than just the stats | 16:08 |
| corvus | so it's belt and suspenders | 16:08 |
| clarkb | corvus: line 1963 sets hold in queue to False then 1990 does the same. I think 1963 might need to set it to True? | 16:09 |
| opendevreview | Sorin Sbârnea proposed zuul/zuul-jobs master: ensure-podman: enable testing of centos-8-stream https://review.opendev.org/c/zuul/zuul-jobs/+/805433 | 16:09 |
| corvus | clarkb: oh neat, actually i think that means we don't need that line -- holding it in build is sufficient to keep it in the executor api memory | 16:10 |
| opendevreview | James E. Blair proposed zuul/zuul master: Adjust test_autohold to catch stats errors https://review.opendev.org/c/zuul/zuul/+/805416 | 16:11 |
| corvus | that actually addresses most of my objections to complexity :) | 16:11 |
| pabelanger[m] | has anyone ever thought or tried to manage backports via a zuul job? Was thinking it might be a good pipeline to create, along with job, to have a zuul job open a change / PR based on some trigger | 17:38 |
| clarkb | opendev does automated change pushes for translation and requirements updates. The only real different thing you'd do for backports is change the trigger mechanism | 17:40 |
| clarkb | the translations and requirements updates are done in a periodic queue, they check for updates once a day and if present push them | 17:40 |
| clarkb | One thing you need to be careful of is pushing a new patchset every day that will never merge. At least with gerrit it didn't like the 600 something patchset chagne that swift ended up with | 17:41 |
| pabelanger[m] | yah, I wrote a job like that too for when we did the ansible collections migration, but it was local. I figured it would be good to push up into zuul-jobs, document and try to support around it. | 17:42 |
| *** mgoddard- is now known as mgoddard | 17:43 | |
| fungi | if your code review system has a "create backport" mechanism integrated, then it may make more sense to just have a zuul job call that somehow rather than creating and pushing commits | 17:51 |
| fungi | either way, the process is going to be stopped by even the most trivial of merge conflicts, so someone's going to have to monitor it and replace or fix up the backports which can't be cleanly applied | 17:52 |
| opendevreview | Merged zuul/zuul master: Fix wrong varible use when updating resource stats https://review.opendev.org/c/zuul/zuul/+/805361 | 17:59 |
| JPEW | Do zuul YAML files support templating (e.g. Jinja2)? I have a lot of rinse and repeat jobs I want to make | 20:35 |
| y2kenny | if I don't have a log_url for a job, the job link in the webui status page points to some finger:// path. Which configuration affect this setup? | 20:39 |
| corvus | JPEW: no, but jobs support inheritance, so the repeating parts should be very small. yaml anchors are supported. | 20:40 |
| corvus | y2kenny: the status page in the current release should always link to the build page now. | 20:41 |
| y2kenny | corvus: um.. ok... I am kind of behind on my upgrade because the nodepool upgrade requirement. I need to update my Cobbler nodepool driver. | 20:43 |
| y2kenny | (need to find time to update it) | 20:43 |
| corvus | y2kenny: i think the option was something like 'report-build-page' try searching for that | 20:44 |
| corvus | it's a tenant config file setting | 20:44 |
| y2kenny | corvus: ok will do | 20:44 |
| y2kenny | thanks | 20:44 |
| clarkb | Also, I beleive you can safely update nodpool first without updating zuul | 20:45 |
| clarkb | which might simplify things if you don't feel they need to be done all at once | 20:45 |
| y2kenny | clarkb: oh that's good to hear | 20:46 |
| y2kenny | Is there a way to access older version of Zuul's documentation? | 20:49 |
| y2kenny | looks like zuul-ci.org/docs is always pointed to the latest? | 20:50 |
| clarkb | they are in the zuul git repo history as rst files so fairly readable that way | 20:50 |
| y2kenny | ok I will try that | 20:50 |
| clarkb | y2kenny: look in the history of doc/source/reference/tenants.rst | 20:51 |
| clarkb | and it is report-build-page, corvus has a good memory | 20:51 |
| corvus | older versions are publishud under their tags | 20:52 |
| corvus | eg https://zuul-ci.org/docs/zuul/4.8.0/ | 20:52 |
| corvus | those are the links i use in the release announcements | 20:52 |
| corvus | which go to zuul-announce@lists.zuul-ci.org friendly reminder that everyone should subscribe to that :) | 20:53 |
| y2kenny | corvus: ooo... that's good to know | 20:53 |
| y2kenny | I probably should do that too... I think I subscribed to discuss but not announce | 20:54 |
| y2kenny | if the versioned doc can have some link on the doc site that would be great | 20:54 |
| fungi | the z-a archive is also available if you want to catch up: http://lists.zuul-ci.org/pipermail/zuul-announce/ | 20:54 |
| fungi | very low-traffic ml | 20:55 |
| corvus | y2kenny: i agree; patches welcome :) | 20:56 |
| corvus | i don't think anyone has figured out an easy way to do it though; i don't think it's trivial | 20:57 |
| y2kenny | The doc pages is done by Sphinx right? I thought I have seen that kind of feature in readthedocs | 20:58 |
| fungi | getting it into the sidebar or a heading as a drop-down selector would likely require some theme adjustments | 20:58 |
| y2kenny | but I am not too familiar with the relationship | 20:58 |
| fungi | yeah, it might be that the alabaster theme we're using has an option you just need to turn on, or there might be an extension which does the heavy lifting | 20:59 |
| corvus | and potentially rebuilding old versions to add new ones? | 20:59 |
| fungi | hard to say, depending on the implementation maybe | 20:59 |
| fungi | or we could just have something which linked you over to the already-built old versions we have | 21:00 |
| *** dviroel|ruck is now known as dviroel|out | 22:04 | |
| opendevreview | James E. Blair proposed zuul/zuul master: WIP Update Matrix instructions https://review.opendev.org/c/zuul/zuul/+/805467 | 22:32 |
| corvus | i'm waiting for the changes to opendev to land before i re-do the screenshots, but maybe folks want to take a look at the text? | 22:33 |
| clarkb | the text seems fine to me | 22:35 |
| opendevreview | James E. Blair proposed zuul/zuul-website master: Update website for Matrix https://review.opendev.org/c/zuul/zuul-website/+/805469 | 22:39 |
| corvus | that one's ready | 22:40 |
| clarkb | I've joined the room. Not sure if I shold but I did >_> | 22:41 |
| clarkb | I wanted to double check ti was there before reviewing and +2ing a change for the website saying it was there :) | 22:41 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!