| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 860987: Change merge mode default based on driver https://review.opendev.org/c/zuul/zuul/+/860987 | 00:32 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Ian Wienand: [zuul/zuul] 860912: Fix typo for zuul_console_disabled flag https://review.opendev.org/c/zuul/zuul/+/860912 | 01:40 | |
| @bingberg:matrix.org | is there any method to access what triggered the current pipeline from a job? we have job that can be run by adding comments to a change and we're looking at some way to get to what the comment actually was from inside the job | 07:49 |
|---|---|---|
| -@gerrit:opendev.org- Simon Westphahl proposed: [zuul/zuul] 861155: Correctly (de-)serialize the topic of a change https://review.opendev.org/c/zuul/zuul/+/861155 | 09:27 | |
| -@gerrit:opendev.org- Marvin Becker proposed: [zuul/nodepool] 853993: Add hold command to disable nodes https://review.opendev.org/c/zuul/nodepool/+/853993 | 10:43 | |
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/nodepool] 851988: Implement cleanup of leaked resources in k8s driver https://review.opendev.org/c/zuul/nodepool/+/851988 | 11:44 | |
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/nodepool] 853151: Fix doc for k8s mem limits as MiB instead of MB https://review.opendev.org/c/zuul/nodepool/+/853151 | 11:52 | |
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/nodepool] 853151: Fix doc for k8s mem limits as MiB instead of MB https://review.opendev.org/c/zuul/nodepool/+/853151 | 11:54 | |
| -@gerrit:opendev.org- Benjamin Schanzel proposed: [zuul/nodepool] 853168: Add config option to limit ephemeral storage on K8s Pod labels https://review.opendev.org/c/zuul/nodepool/+/853168 | 11:57 | |
| -@gerrit:opendev.org- Benedikt Löffler proposed: [zuul/nodepool] 860470: Cleanup local builds without .d folder https://review.opendev.org/c/zuul/nodepool/+/860470 | 12:52 | |
| @jim:acmegating.com | bingberg: no, and that's intentional. zuul is designed so that regardless of what triggered a change to be enqueued in a pipeline, the jobs are deterministic. depending on circumstances, if you're trying to accommodate a certain workflow, you might consider adding new pipelines. | 12:58 |
| @bingberg:matrix.org | that's too bad, our use-case is that we want the developers to be able to ask zuul to manually trigger a specific later stage job from the pipeline | 14:09 |
| @bingberg:matrix.org | so our solution is to have a manual-test pipeline which is triggered by a comment, where the comment says which job is relevant and we simply skip all unrelated jobs | 14:09 |
| @bingberg:matrix.org | but I guess we'll solve it by having the job ask the gerrit server about and parse out which comment was the actual trigger, it's simply a step we wished to be able to avoid since zuul knows what triggered the pipeline | 14:13 |
| @fungicide:matrix.org | zuul's main focus is gating changes, i.e. preventing them from merging if they don't pass tests and merging them automatically once they do (so long as other requirements are also satisfied). key to that is repeatability and determinism in the jobs it runs, since you don't want differences in build results to end in the branch being untestable for the next change | 14:26 |
| @bingberg:matrix.org | yeah, but if you are fixing a bug in a gate job, or even a post job, it's nice to be able to run those jobs without having to merge the code | 14:28 |
| @fungicide:matrix.org | yes, designing the jobs so that they can run the same way in any pipeline is an important part of making that possible | 14:29 |
| @bingberg:matrix.org | yeah so that's what we use the manual pipeline for today, it runs the same jobs as our check/gate/post pipelines, but you can trigger it manually for a specific change | 14:30 |
| @clarkb:matrix.org | What we do for that use case is to push a change that edits the zuul.yaml to remove the unnecessary jobs while developing a fix. Then when ready to merge you restore the zuul.yaml | 14:30 |
| @clarkb:matrix.org | You can also modify pipelines to run copies of a job many times if trying to catch infrequent errors | 14:31 |
| @bingberg:matrix.org | doesn't that create issues where someone merges something that wouldn't pass a gate check while you are developing? and then when you restore the zuul.yaml it breaks again? | 14:32 |
| @clarkb:matrix.org | Well they shouldn't merge anything that won't pass gating. You only use the modified zuul.yaml pre merge while developing a fix. Then push a new patch set to restore zuul.yaml prior to merging | 14:34 |
| @jim:acmegating.com | This is me making an alteration to zuul's check jobs that we will not merge, in order to track down a specific issue: https://review.opendev.org/860984 | 14:36 |
| @jim:acmegating.com | it's a similar mechanism to the idea Clark was talking about | 14:37 |
| @fungicide:matrix.org | that workflow of course hinges on zuul's ability to run with proposed alterations to job configuration in untrusted repositories | 14:38 |
| @fungicide:matrix.org | speculatively executing unmerged changes to its own configuration | 14:39 |
| @fungicide:matrix.org | it's not a common feature of other ci/cd systems, so many people new to zuul don't consider the option of doing that | 14:40 |
| @bingberg:matrix.org | anyway, getting a hold of the pipeline trigger wasn't a feature we had in zuul2 either, we were just curious if we could simplify the implementation for new zuul | 14:58 |
| @bingberg:matrix.org | we'll simply have to ask the gerrit server to figure it out | 14:59 |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 861155: Correctly (de-)serialize the topic of a change https://review.opendev.org/c/zuul/zuul/+/861155 | 15:09 | |
| @clarkb:matrix.org | swest: on https://review.opendev.org/c/zuul/zuul/+/861155/1/zuul/model.py do we need to special case topic == None cases? Otherwise all changes without a topic might be considered to have the same topic? | 15:52 |
| @clarkb:matrix.org | maybe that is already done since it is valid to not have at topic normally | 15:54 |
| @westphahl:matrix.org | Clark: IIRC this is already done before querying the topic | 15:57 |
| @clarkb:matrix.org | ok. It won't affect opendev since we don't run with same topic merges | 15:57 |
| @westphahl:matrix.org | https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/gerrit/gerritsource.py#L147 | 16:00 |
| @jim:acmegating.com | also, current values for multi-scheduler setups are None because of the bug (it's set in the initializer to None and just not restored). so we know that is behaving as expected. | 16:01 |
| @clarkb:matrix.org | good point | 16:01 |
| @clarkb:matrix.org | Does anyone know if delegating a set_fact task to localhost is appreciably quicker than running it on the remote node? I'm wondering if that cuts down on some of the ansible task startup costs. And since we are just manipulating internal ansible state with set_fact we can get away with running it on localhost rather than the remote | 16:20 |
| @clarkb:matrix.org | corvus: do you need to put the fix below https://review.opendev.org/c/zuul/zuul/+/860983/ to allow the two debugging chagnes to merge reliably? | 16:54 |
| @jim:acmegating.com | Clark: re set_fact i *think* it doesn't matter, but i'm not 100% sure. re other, yeah, that's probably worth doing :) | 17:27 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: | 17:28 | |
| - [zuul/zuul] 861104: Fix shutdown race in timer driver https://review.opendev.org/c/zuul/zuul/+/861104 | ||
| - [zuul/zuul] 860983: Add debugging to waitUntilSettled https://review.opendev.org/c/zuul/zuul/+/860983 | ||
| - [zuul/zuul] 861102: Add timer driver debugging https://review.opendev.org/c/zuul/zuul/+/861102 | ||
| - [zuul/zuul] 860984: DNM: run lots of unit tests https://review.opendev.org/c/zuul/zuul/+/860984 | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 860987: Change merge mode default based on driver https://review.opendev.org/c/zuul/zuul/+/860987 | 17:31 | |
| -@gerrit:opendev.org- Tobias Henkel proposed: [zuul/zuul] 861211: Always initialize the github client manager https://review.opendev.org/c/zuul/zuul/+/861211 | 18:09 | |
| -@gerrit:opendev.org- Tobias Henkel proposed: [zuul/zuul] 861211: Always initialize the github client manager https://review.opendev.org/c/zuul/zuul/+/861211 | 18:14 | |
| -@gerrit:opendev.org- Tobias Henkel proposed: [zuul/zuul] 861211: Always initialize the github client manager https://review.opendev.org/c/zuul/zuul/+/861211 | 18:15 | |
| @vlotorev:matrix.org | > <@bingberg:matrix.org> that's too bad, our use-case is that we want the developers to be able to ask zuul to manually trigger a specific later stage job from the pipeline | 18:44 |
| bingberg: having limited resources of embedded devices we are choosing what tests to run in check pipeline via git commit trailers, like: | ||
| ``` | ||
| Tests: <pytest-expression> | ||
| Change-Id: ... | ||
| ``` | ||
| Gate pipeline can run all tests unconditionally. | ||
| Extending this idea it's possible to have dispatcher zuul job that skips dependent jobs after analyzing commit message. | ||
| Google Chromium uses 'TEST=' trailers like in https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/3954019 | ||
| Not sure if Chromium CI analyzes that though. | ||
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 861104: Fix shutdown race in timer driver https://review.opendev.org/c/zuul/zuul/+/861104 | 18:52 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 860983: Add debugging to waitUntilSettled https://review.opendev.org/c/zuul/zuul/+/860983 | 19:03 | |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: | 19:04 | |
| - [zuul/zuul] 861102: Add timer driver debugging https://review.opendev.org/c/zuul/zuul/+/861102 | ||
| - [zuul/zuul] 860877: Add "draft" github pipeline requirement https://review.opendev.org/c/zuul/zuul/+/860877 | ||
| @mordred:inaugust.com | Clark: set_fact is an action plugin and always actually executes on the localhost IIRC - so I do not think delegation will do anything | 19:25 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 860878: Expand github pipeline reject docs https://review.opendev.org/c/zuul/zuul/+/860878 | 20:19 | |
| @clarkb:matrix.org | > <@mordred:inaugust.com> Clark: set_fact is an action plugin and always actually executes on the localhost IIRC - so I do not think delegation will do anything | 20:55 |
| ya I figured it wouldn't help. I'm just looking at loops in stage-output and wondering how I can get rid of them in a straightforward way or speed them up. Unfortunately it seems like rewriting things to be modules and expanding the scope of those modules over time may be what is necessary | ||
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!