| sean-k-mooney | bauzas: i know your likely bussy with the spec review day, how would you feel about moving forward with some of my strawman propsoal https://review.opendev.org/q/topic:%22strawman%22 | 14:35 |
|---|---|---|
| bauzas | I started to look at them a few weeks before but we can review them next week if you want | 14:36 |
| sean-k-mooney | ack i have not updated them i na while so i think im oging to do an update of them in a day or to and drop out a few things liek the nix patch | 14:36 |
| sean-k-mooney | i have been usign thse locally since i pushed them and the commit message sik in partically has been very nice ot have | 14:37 |
| sean-k-mooney | i built a littel poc with the full set https://github.com/SeanMooney/oslo.bubblewrap | 14:38 |
| sean-k-mooney | to try them out and it turnd out ok | 14:38 |
| sean-k-mooney | but im also aware that there is a patch form glance and neutorn for addign project knowldage | 14:39 |
| sean-k-mooney | so ya let find some time next week | 14:39 |
| fungi | zuul can trigger enqueuing into a pipeline based on gerrit label values, this is for example how it automatically enqueues a change into the gate poipeline as soon as check pipeline jobs succeed: https://opendev.org/openstack/project-config/src/commit/ac9ab14/zuul.d/pipelines.yaml#L88-L91 | 17:54 |
| fungi | it could just as easily have the event condition be `Verified: -1` | 17:54 |
| sean-k-mooney | oh i like that | 17:55 |
| sean-k-mooney | your totally right | 17:55 |
| fungi | (sorry for necroing a discussion from yesterday, just happened to spot it in scrollback) | 17:56 |
| sean-k-mooney | so i could trivaly defien a check-fail pipelien in my third party ci or the first party one | 17:56 |
| sean-k-mooney | fungi: dont be i was aware of that fucntionltiy but never tought ot actully trigger on -1 for verifed | 17:56 |
| fungi | yeah, basically the zuul service could react to its own account's verified -1 vote, or that of another zuul | 17:57 |
| sean-k-mooney | yep that a pretty clean way to do that too although | 17:57 |
| sean-k-mooney | im not sure if we can get the reelvent build set info form that | 17:57 |
| sean-k-mooney | maybe we can | 17:57 |
| fungi | in our upstream gate pipeline triggers we have our zuul listen for its own +1 vote, essentially, so as not to react to third-party ci systems, but you could flip that around | 17:57 |
| sean-k-mooney | i would have to see what in the gerrit info passs to zuul | 17:57 |
| fungi | i think we have some samples for test fixtures... just a sec | 17:58 |
| sean-k-mooney | assuming it gets the full -1 comment info | 17:59 |
| sean-k-mooney | that woudl containe the links to the build results | 17:59 |
| sean-k-mooney | which another job could then use to grab the relevent logs | 17:59 |
| fungi | https://opendev.org/zuul/zuul/src/branch/master/tests/fakegerrit.py has some sample events | 18:00 |
| sean-k-mooney | the comemnt it lest is somethig liek this https://paste.opendev.org/show/b3LL4izVMIiyqFl67mPW/ | 18:00 |
| sean-k-mooney | the simplet thing to do would be just add the noop job | 18:01 |
| sean-k-mooney | and look at the logs that are collected | 18:01 |
| sean-k-mooney | it will have teh inventory and standard zuul artifacts | 18:01 |
| fungi | yeah, looks like the comment has a message string | 18:02 |
| sean-k-mooney | yep which is what the regex on teh comment triger matches on | 18:03 |
| fungi | and, well, we do also use that in the pipeline config i mentioned earlier, for rechecks in the check pipeline definition if you're looking for a functional example | 18:03 |
| fungi | right that | 18:03 |
| sean-k-mooney | im not sure we actully get that in full in the zuul job info in the inventory or not but we might | 18:03 |
| fungi | oh, in the inventory vars? yeah i know we've talked about that but can't remember if it's exposed... looking | 18:04 |
| sean-k-mooney | im going to check one of my recent rechecks | 18:05 |
| sean-k-mooney | im sure it woudl not be hard to add if tis not there today | 18:05 |
| fungi | i think it's this b64 encoded string: https://zuul.opendev.org/t/openstack/build/4d13c3b44c2d47e0a53a50fd0587bd63/log/zuul-info/inventory.yaml#163 | 18:05 |
| sean-k-mooney | that the commit message | 18:06 |
| sean-k-mooney | Add Flamingo Support | 18:06 |
| sean-k-mooney | Change-Id: I2648275515e922a9b5f2602ab11a45ab0008390b | 18:06 |
| fungi | ah no, that's just an encoded version of `change_message` | 18:06 |
| sean-k-mooney | i think its not aviabel today form the last iti mi checked | 18:07 |
| sean-k-mooney | i was looking into th eidea fo passing a prom to an llm via the comment | 18:08 |
| sean-k-mooney | and i dont think that was posssible a few month ago | 18:08 |
| sean-k-mooney | but this exact feature was requested in the zuul channel befor ethe ptg | 18:08 |
| sean-k-mooney | ya so https://zuul.opendev.org/t/openstack/build/1d140a619b5e4f499346d1bc50abeb0f/log/zuul-info/inventory.yaml was tirggered by a recheck but it does not have the trigger info or the comment embded | 18:10 |
| sean-k-mooney | with that said i dont know fi that invetory is genreated by our base jobor zuul itself | 18:10 |
| sean-k-mooney | so it may be aviabel but just not included | 18:10 |
| fungi | yeah, i'm pretty sure if comment-added message strings were made abailable from the gerrit source driver, it would be included in the list of vars documented at https://zuul-ci.org/docs/zuul/latest/job-content.html#zuul-variables | 18:16 |
| sean-k-mooney | and you could do this for other driver too like github | 18:17 |
| fungi | for the most part, zuul tries to push users toward job definitions that are reproducible for the same source code state, and having a job alter its behavior depending on how it got scheduled would violate that principle | 18:17 |
| sean-k-mooney | so its not gerrit only | 18:17 |
| fungi | so i'm pretty sure that's why we pushed back on adding such a feature when its come up in the past | 18:18 |
| sean-k-mooney | ya of couse if you jsut leave the same comment it woudl be as repoducebal as any llm triger would be | 18:18 |
| fungi | using message strings in the scheduling decision process is fine, but they shouldn't alter how the job runs once it's been scheduled | 18:19 |
| sean-k-mooney | which is some interninate value above 0. i wil not comment on how much grater then 0 it is | 18:19 |
| sean-k-mooney | sure but there is noting stopinmg me as a job author form curlign gerrit adn geting the most recent commnt before the job started | 18:20 |
| sean-k-mooney | so i can defintly make it work out side of native supprot if i was inclined to do so | 18:20 |
| fungi | right, there are ways to go around zuul to fetch data directly from the code review system, zuul just doesn't encourage that and doesn't add features to support doing so | 18:21 |
| sean-k-mooney | fungi: how did eleasetic recheck wrok? do you recall? | 18:21 |
| fungi | yes, it listened on the gerrit event stream and any time it saw a job failure it ran a query over the indexed job logs looking for matches to recorded known bug signatures, then left a review comment suggesting which bug it was likely to be that caused the job failure | 18:22 |
| sean-k-mooney | ah so it just consumed the gerrit stram directly rather then being triggerd by zuul | 18:23 |
| fungi | it wasn't implemented in zuul, it was just an external loop listening to gerrit comments from zuul and then adding more gerrit comments of its own | 18:23 |
| sean-k-mooney | ya, so monty's openclaww gerrit coudl do that | 18:24 |
| fungi | it also had an accompanying irc bot which reported matches in channels that asked for them, but that's probably less relevant to this discussion | 18:24 |
| opendevreview | Steve Baker proposed openstack/agentic-workflows master: docs: add OpenCode instructions to README https://review.opendev.org/c/openstack/agentic-workflows/+/991740 | 20:57 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!