| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 886666: Update Azure API and add volume-size https://review.opendev.org/c/zuul/nodepool/+/886666 | 01:17 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 01:23 | |
| - [zuul/nodepool] 881287: Add Azure gallery image support https://review.opendev.org/c/zuul/nodepool/+/881287 | ||
| - [zuul/nodepool] 886666: Update Azure API and add volume-size https://review.opendev.org/c/zuul/nodepool/+/886666 | ||
| @tcarrez:matrix.org | Re: rooms stuck unread in Matrix, it seems to be related with usage of "discussion threads" (when one of my rooms is stuck unread it's usually that there is a discussion thread I haven't "read" yet) | 07:13 |
|---|---|---|
| @harbott.osism.tech:regio.chat | > <@tcarrez:matrix.org> Re: rooms stuck unread in Matrix, it seems to be related with usage of "discussion threads" (when one of my rooms is stuck unread it's usually that there is a discussion thread I haven't "read" yet) | 07:17 |
| yes, the unsolved UX issue seems to be to be able to easily identify those threads | ||
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 886732: Log item related messages with event id https://review.opendev.org/c/zuul/zuul/+/886732 | 09:22 | |
| @fungicide:matrix.org | aha, found it. there's a little dot to the right of unread threads in the thread list. looks like there are a lot of threads i need to click on to make them no longer show up as unread. maybe that changed recently | 15:54 |
| @fungicide:matrix.org | confirmed: after i found time to click the (dozens of) threads from the past year with a dot next to them, the unread dot next to this channel also finally cleared | 16:44 |
| @harbott.osism.tech:regio.chat | with my fresh account I only saw four threads, so I guess I can call myself lucky about a) having switched and b) this not affecting threads created before joining the room :D | 16:48 |
| @fungicide:matrix.org | anyway, for anyone trying to figure out "which thread did i miss that's keeping the channel unread" the trick is to skim the thread list sidebar looking for a thread with a dot (or maybe message count icon) to the immediate right of it | 16:50 |
| @jim:acmegating.com | then maybe go and thumbs-up this issue: https://github.com/vector-im/element-meta/issues/1090 :) | 17:57 |
| @fungicide:matrix.org | done | 18:21 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/nodepool] 886785: Add REPL https://review.opendev.org/c/zuul/nodepool/+/886785 | 20:17 | |
| @sdodsley:matrix.org | I'm not even sure how to phrase this question. I have zuul configured to run openstack patches as part of our third party CI. Patches successfully go into the pipeline, but when the jobs are supposed to start nothing happens and the patch just drops out of the pipeline. I have both scheduler and executor running in debug mode and tere are no messages suggesting why the jobs aren't working. Any suggestions as to where I can look to find why jobs are not starting? | 22:21 |
| @sdodsley:matrix.org | I'm wondering if this is an indicator, but not sure what it's actually trying to tell me | 22:47 |
| ``` | ||
| scheduler.log-20230622:2023-06-22 03:14:53,031 DEBUG zuul.Pipeline.third-party-ci.thirdparty-check: [e: 531f489938364e39b97b7bd7fa46e50f] Event <GerritTriggerEvent comment-added opendev.org/openstack/cinder master 885596,3 Verified:0, Code-Review:0, Workflow:0, Review-Priority:0> for change <Change 0x7f9fd82f6cf8 openstack/cinder 885596,3> does not match <GerritEventFilter connection: opendev-third-party-ci types: comment-added ignore_deletes: True comments: (?i)^(Patch Set [0-9]+:)?( [\w\\+-]*)*(\n\n)?\s*run Pure Storage CI\s*$> in pipeline <IndependentPipelineManager thirdparty-check> because False | ||
| ``` | ||
| @clarkb:matrix.org | I usually do two things in that scenario. First is quickly checking for file matchers that would cause jobs to be skipped (a very common case). Second is grepping logs using the event id for the event and then tracing through it to see where it gets unhappy | 22:48 |
| @clarkb:matrix.org | That log line indicates one reason jobs aren't running because that specific condition of 'run pure storage' isn't set. But there may be other conditions that would trigger anyway | 22:49 |
| @sdodsley:matrix.org | so when I reply `run Pure Storage CI` in th epatch the patch does get into the pipeline, but the jobs don't start, so doesn't that mean the trigger regex is correct? | 22:51 |
| @clarkb:matrix.org | Every event is evaluated by every pipeline and can show up in the pipeline at least briefly | 22:56 |
| @clarkb:matrix.org | That does seem to indicate that the event isn't matching | 22:57 |
| @clarkb:matrix.org | I would look in your logs to find the event that match to your run comment and then grep on the associated event id and trace that | 22:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!