| -@gerrit:opendev.org- Zuul merged on behalf of Joshua Watt: [zuul/zuul] 837879: gerrit: Fix 'form' auth https://review.opendev.org/c/zuul/zuul/+/837879 | 00:01 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Dong Zhang: [zuul/zuul] 839370: Fix a bug that re-enqueue may skip soft dependent jobs https://review.opendev.org/c/zuul/zuul/+/839370 | 00:01 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Guillaume Chauvel: [zuul/zuul] 839728: tutorial: quick-start doc: Fix filename style https://review.opendev.org/c/zuul/zuul/+/839728 | 00:01 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 832518: Fix Github debugging script https://review.opendev.org/c/zuul/zuul/+/832518 | 00:01 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Simon Westphahl: [zuul/zuul] 831906: Ignore deleted nodes when looking for lost params https://review.opendev.org/c/zuul/zuul/+/831906 | 00:04 | |
| -@gerrit:opendev.org- Zuul merged on behalf of Albin Vass: [zuul/zuul] 831933: gerritdriver: enable triggering on wip state https://review.opendev.org/c/zuul/zuul/+/831933 | 00:05 | |
| @fungicide:matrix.org | > <@y2kenny:matrix.org> thanks for identifying that. How did you spot that quickly? (I see a lot of error and exception and a wall of text when I look at the test reports... I am not sure how to narrow it down quicker.) | 12:10 |
|---|---|---|
| i expanded the output from one of the failing tests in the test results table and skimmed for "Traceback" as a starting point, skipping over any tracebacks which looked like they were intentional from negative testing and with an eye for the function name you were calling and the file you were modifying in your change | ||
| @fungicide:matrix.org | in my experience, when i get test failures on a change it's often because my change is wrong, so i start looking for obvious signs that's the case and only broaden my search for the cause if i don't find something i caused | 12:11 |
| -@gerrit:opendev.org- chandan kumar proposed: [zuul/zuul-jobs] 839938: [DNM] ovs debug https://review.opendev.org/c/zuul/zuul-jobs/+/839938 | 12:20 | |
| -@gerrit:opendev.org- Joshua Watt proposed: [zuul/zuul] 839950: doc: Add clarification note for branches attribute https://review.opendev.org/c/zuul/zuul/+/839950 | 13:39 | |
| @jpew:matrix.org | I struggled with job `branches` also, and I *think* I finally grok this; does https://review.opendev.org/c/zuul/zuul/+/839950 help maybe? | 13:41 |
| @y2kenny:matrix.org | jpew: That is useful. But what do you use as an alternative instead? Also, how did you debug when jobs are not running due to multiple variants? | 14:06 |
| @jpew:matrix.org | Kenny Ho: I don't know how to prevent job variants from getting created based on branch (although that is something I would find useful) | 14:07 |
| @jpew:matrix.org | TBH, I didn't "debug" is so much as I finally understood what `branches` means, and realized I needed to remove all of them from our configs :) | 14:08 |
| @jpew:matrix.org | Which I'm currently testing to see if if fixes the problems we were seeing (I suspect it will) | 14:08 |
| @y2kenny:matrix.org | the thing is, the branches has been working for us in the way I thought it should but only running into the non-triggering issue recently. | 14:10 |
| @y2kenny:matrix.org | and it's unclear to me under what condition the branch can work like a filter and when it does not. (Or may be I am just lucky to hit the right combination) | 14:11 |
| @y2kenny:matrix.org | like may be I haven't been filtering with master branches when the configs are stored in master branches. | 14:12 |
| @jpew:matrix.org | It "appeared" to work for us, until we changed the configuration on the master branch and it didn't do anything because the definition on a different branch was overriding it | 14:12 |
| @jpew:matrix.org | s/definition/variant/g | 14:13 |
| @y2kenny:matrix.org | so what did you ended up doing? did you create job with different name specifically for different branches? | 14:14 |
| @jpew:matrix.org | I'm not sure how we are going to solve it yet | 14:14 |
| @jpew:matrix.org | The biggest problem (ATM) is that we have our master branch push daily build artifacts to a server, and we don't want every branch do do that; that's easy to fix though because we have a variable that controls that so we can pretty simply do: | 14:16 |
| ``` | ||
| - job: | ||
| vars: | ||
| push_artifacts: '{{ zuul.branch == "master" }}' | ||
| ``` | ||
| @jpew:matrix.org | I think this will work, testing it now | 14:16 |
| @jpew:matrix.org | Preventing the job from running at all is an exercise for later | 14:16 |
| @y2kenny:matrix.org | ok. | 14:17 |
| @y2kenny:matrix.org | Being able to filter jobs by branches seems basic... I feel like I am still missing something... | 14:21 |
| -@gerrit:opendev.org- Joshua Watt proposed: [zuul/zuul] 839950: doc: Add clarification note for branches attribute https://review.opendev.org/c/zuul/zuul/+/839950 | 14:23 | |
| @clarkb:matrix.org | > <@y2kenny:matrix.org> Being able to filter jobs by branches seems basic... I feel like I am still missing something... | 14:25 |
| The key thing is that the branches: specifier applies to the version of the job it is directed attached to. If you have another version of the job somewhere else it's branches: config will apply to it. If they both apply to the same branch(es) you get a mash up of the two when the job finally runs. | ||
| @clarkb:matrix.org | This means you can filter by branch, you just have to be careful you don't have multiple conflicting/colliding filters | 14:25 |
| @jpew:matrix.org | Clark: Ya, I think what we want is to have the jobs defined and run on master, but *not* any branches that split off of master (by default at least) | 14:27 |
| @clarkb:matrix.org | * The key thing is that the branches: specifier applies to the version of the job it is directly attached to. If you have another version of the job somewhere else it's branches: config will apply to it. If they both apply to the same branch(es) you get a mash up of the two when the job finally runs. | 14:27 |
| @clarkb:matrix.org | > <@jpew:matrix.org> Clark: Ya, I think what we want is to have the jobs defined and run on master, but *not* any branches that split off of master (by default at least) | 14:28 |
| The way I would achieve that is to define the job(s) in a repo with a single branch. Then specify branches: master on that definition. Then you have a single definition that applies to a single branch | ||
| @y2kenny:matrix.org | for me, I have job defined in a master branch of a centralized repo, but triggers off different branches of different repo | 14:29 |
| @y2kenny:matrix.org | for example, I have all the job definition in a repo call zuul-jobs (in master branch) and a trusted-project call zuul-project (also master branch) that defines the trigger, using jobs from zuul-jobs. | 14:32 |
| @y2kenny:matrix.org | in zuul-projects, the jobs are used with branch: to trigger off of events that is neither zuul-projects or zuul-jobs (i.e., linux-kernel, etc.) | 14:34 |
| @y2kenny:matrix.org | zuul-jobs repo is untrusted so that we can do pre-submit testing on job definition. zuul-projects are trusted to be able to use jobs from else. This arrangement has been working so far but recently I got a trigger that is defined in zuul-projects that is not launch the job | 14:38 |
| @y2kenny:matrix.org | it's interesting because other jobs defined with the trigger launched | 14:39 |
| @clarkb:matrix.org | Kenny Ho: the problem is a change to some branch in another repo (linux-kernel for example) isn't triggering the expected jobs defined by zuul-jobs or zuul-projecte? | 14:39 |
| @y2kenny:matrix.org | yes... and only some of the job | 14:39 |
| @clarkb:matrix.org | The first thing I would check in that case is file matchers. But that may be a bias to our users using them extensively then often wondering why jobs don't run | 14:40 |
| @clarkb:matrix.org | For our installation that is probably the most common cause of this behavior | 14:40 |
| @y2kenny:matrix.org | so what I have is something like, build-kernel, and build-userspace, and make-container-image job | 14:41 |
| @y2kenny:matrix.org | they are all defined in zuul-jobs, with trigger defined in zuul-project to kick off with event from linux-kernel | 14:41 |
| @y2kenny:matrix.org | and what I am seeing is that build-kernel and build-userspace kicks off but not make-container-image job | 14:42 |
| @y2kenny:matrix.org | the special thing about the make-container-image job is that it actually inherit from another job defined in another repo (called dockerfiles) | 14:43 |
| @jim:acmegating.com | Kenny Ho: https://zuul-ci.org/docs/zuul/latest/config/project.html#attr-project.%3Cpipeline%3E.debug may help you determine why a job doesn't run. also, the same information is available in the scheduler log if it's logging at debug level. | 14:44 |
| @y2kenny:matrix.org | I will probably untangle this but I am interested to know why this arrangement is special and cause make-container-image job not work | 14:44 |
| @y2kenny:matrix.org | corvus: thanks. I will dig into that. Now that I think about it some more, may be it is the file-filter issue | 14:46 |
| @y2kenny:matrix.org | the job defined in the dockerfiles repo has file filter for the files in dockerfiles, but when triggering off by linux-kernel, it obviously doesn't have the same files. | 14:50 |
| -@gerrit:opendev.org- Mirzad Mohandespour proposed: [zuul/zuul] 839784: Fix a typo in quick-start tutorial https://review.opendev.org/c/zuul/zuul/+/839784 | 16:06 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!