| *** tosky has quit IRC | 00:57 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #zuul | 05:33 | |
| *** sshnaidm|pto is now known as sshnaidm | 08:43 | |
| *** zbr0 has joined #zuul | 09:18 | |
| *** zbr has quit IRC | 09:21 | |
| *** zbr0 is now known as zbr | 09:21 | |
| *** zbr3 has joined #zuul | 09:27 | |
| *** zbr has quit IRC | 09:29 | |
| *** zbr3 is now known as zbr | 09:29 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Add messages to make the job setup more transparent https://review.opendev.org/c/zuul/zuul/+/777885 | 09:58 |
|---|---|---|
| avass | tobiash: how about that? ^ | 09:58 |
| *** zbr has quit IRC | 10:20 | |
| *** zbr has joined #zuul | 10:22 | |
| *** jangutter has quit IRC | 10:40 | |
| *** jangutter has joined #zuul | 10:41 | |
| *** zbr7 has joined #zuul | 10:41 | |
| *** zbr has quit IRC | 10:43 | |
| *** zbr7 is now known as zbr | 10:43 | |
| *** zbr4 has joined #zuul | 11:06 | |
| *** zbr has quit IRC | 11:08 | |
| *** zbr4 is now known as zbr | 11:08 | |
| avass | corvus: I'm starting to think that having non-overrideable variables would be nice, I know there's executor.variables but something like zuul-cache-s3 could potentially need different variables per tenant | 11:08 |
| avass | do variables from secrets have higher precendece than anything else? | 11:13 |
| *** tosky has joined #zuul | 11:53 | |
| *** bodgix has quit IRC | 13:30 | |
| *** jangutter has quit IRC | 13:33 | |
| *** jangutter has joined #zuul | 13:33 | |
| *** bodgix has joined #zuul | 13:34 | |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 13:41 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 13:44 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 13:52 |
| *** jangutter has quit IRC | 13:54 | |
| *** jangutter has joined #zuul | 13:55 | |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 14:14 |
| *** jangutter has quit IRC | 14:16 | |
| *** jangutter has joined #zuul | 14:16 | |
| openstackgerrit | Albin Vass proposed zuul/zuul master: Reduce amount of 'Waiting on logger' messages sent https://review.opendev.org/c/zuul/zuul/+/777887 | 14:19 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 14:23 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 14:27 |
| openstackgerrit | Albin Vass proposed zuul/zuul-jobs master: Zuul Cache role with s3 implementation. https://review.opendev.org/c/zuul/zuul-jobs/+/764808 | 14:40 |
| avass | interesting, ansible really wants to scrub the AWSAccessKeyId from those presigned urls so the urls break. | 15:08 |
| corvus | avass: close -- job extra vars can override secrets: https://zuul-ci.org/docs/zuul/reference/jobs.html#variables | 15:12 |
| avass | corvus: ah, I was looking for that in the 'Configuration syntax' page :) | 15:35 |
| avass | adding something like a 'final-vars' that has a precedence between site-vars and extra-vars could in that case be useful to have | 15:36 |
| sassyn | hi everyone | 16:30 |
| avass | sassyn: hey | 16:34 |
| sassyn | Hi avass | 17:00 |
| sassyn | How are you? | 17:00 |
| sassyn | quick question - I have setup zuul and all is working as expected. I have a REPO X which is configured as untrusted project. | 17:00 |
| sassyn | in REPO X there is a .zuul.yaml file in the master branch. | 17:01 |
| sassyn | Doing a commit fire up the check and gate jobs and my ansible are running as expcted. | 17:01 |
| sassyn | Now I have put in branch FOO a new .zuul.yaml file. this file is not the same as the .zuui.yaml in the MASTER. However when I fire change to the FOO BRANCH the CHECK AND GATE do nothing. | 17:02 |
| sassyn | looking in the log of the scheduler | 17:03 |
| sassyn | I see the change bla bla bla did not merge because it did not have any jobs configured. | 17:04 |
| sassyn | What do I miss? | 17:04 |
| sassyn | any idea? thanks | 17:04 |
| fungi | sassyn: did you include explicit branch matchers in the .zuui.yaml on the new branch? | 17:05 |
| fungi | er, .zuul.yaml | 17:06 |
| sassyn | no | 17:06 |
| sassyn | hi fungi :-) | 17:06 |
| sassyn | how are you? | 17:06 |
| fungi | doing well! | 17:06 |
| sassyn | good to hear.... Here in israel we started to get vaccine for the covid. | 17:06 |
| fungi | do the jobs you added on that branch have parents in another repository with explicit branch matchers? or parents in a branched repository which don't have a matching branch? | 17:07 |
| sassyn | the job in the FOO branch are all belongs to a REPO name ZuulJobs. all the ansible playbook are presented there. in the main branch of ZuulJobs. | 17:09 |
| sassyn | so foo as a .zuul.yaml that looks like this : -project: gate: jobs: - my_job_from_zuul_jobs_repo_in_the_main_branch | 17:10 |
| sassyn | foo is a branch in the REPO X. the job runs OK in the MAIN branch of REPO X | 17:11 |
| fungi | does the ZuulJobs repo have additional branches too, or just a default branch? | 17:17 |
| sassyn | just default branch | 17:18 |
| fungi | double-check that zuul isn't complaining about any configuration errors. that's an easy way to cause it not to load configuration from a project/branch | 17:19 |
| sassyn | so to do smart-reconfigure? | 17:20 |
| fungi | sassyn: zuul-web will show a "bell" icon in the top-right corner if there are configuration errors for the tenant you've selected | 17:21 |
| sassyn | the gui doesn't point out for any configuration issue (the yellow mark on the gui doesn't have the bell | 17:21 |
| fungi | sassyn: also there's this pipeline setting you can try, though i don't know if it will help if nothing is being reported: https://zuul-ci.org/docs/zuul/reference/project_def.html#attr-project.%3Cpipeline%3E.debug | 17:21 |
| fungi | sassyn: and worst case, you can look in the scheduler's debug logs where it should explain every enqueuing decision it made about a particular event | 17:22 |
| sassyn | I'm checking the debug | 17:26 |
| sassyn | log | 17:26 |
| sassyn | fungi - can I share with u the job log? | 17:27 |
| sassyn | in pastebin? | 17:28 |
| fungi | sassyn: sure, you may want to work out the event [e: ...] for your commit push and filter by that first, since all the relevant lines should be tagged with it | 17:34 |
| sassyn | pastebin.pl/view/f8606d81 | 17:38 |
| sassyn | https://pastebin.pl/view/f8606d81 | 17:38 |
| sassyn | myrepo is the name the of the repo | 17:38 |
| sassyn | v0.13.0 is the branch | 17:39 |
| sassyn | 58407/1 is my change in gerrit | 17:40 |
| *** cloudnull has quit IRC | 17:48 | |
| *** cloudnull has joined #zuul | 17:48 | |
| sassyn | line 91 report the issue | 17:51 |
| fungi | sassyn: and you expected zuul_myrepo_build to run for it, i suppose? | 18:00 |
| sassyn | yes | 18:01 |
| fungi | it looks like it has variants for BranchMatcher:master and BranchMatcher:staging (the log also tells you which locations it found those variants defined at) | 18:02 |
| sassyn | what does it mean? | 18:02 |
| fungi | i expect the problem is that you have zuul_myrepo_build defined in a branched repository, and you're wanting to trigger it from another repository with different branch names than the repository in which that job was defined | 18:03 |
| fungi | since your Zuul repository where zuul_myrepo_build is defined has multiple branches (named master and staging) it's assumed those should only match events in other projects for branches with the same names | 18:04 |
| sassyn | so Zuul repo should include also the branch for the REPO X. | 18:05 |
| fungi | so if myrepo had a staging branch and 58407 was proposed targeting that branch, then it would match the zuul_myrepo_build variant defined in the staging branch of Zuul | 18:05 |
| fungi | or if the Zuul repo had a variant of that job in a v0.13.0 branch, yes | 18:05 |
| fungi | usually it's easiest when defining jobs you want used in other projects to either do that in a single-branch repository, or in a repository with branch names which match the banches for the repositories which want to run the job | 18:06 |
| fungi | if the Zuul repository had no staging branch, only a default master branch, then the definition of zuul_myrepo_build in it would be assumed to match any branch of other projects | 18:07 |
| fungi | there are workarounds however | 18:07 |
| sassyn | so the ZUUL REPO which holds all the Zuul jobs and playbook should basically have a branch name Y,Z,M ..... so If a commit a code to REPO Y under branch Y, where the .zuul.yaml is using a Job myjob then it is expeted that ZULL REPO will have brnach Y as well. | 18:08 |
| fungi | for example in myrepo you could specifically say what fallback branch you wanted to get job definitions from in other repositories | 18:08 |
| sassyn | i can't delete the staging branch from Zuul repo | 18:09 |
| fungi | sassyn: in the simple case, yes. as i said, there are ways for you to specify what branch you meant, so you could map myrepo:v0.13.0 to Zuul:master that way, for example | 18:09 |
| fungi | sassyn: https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.required-projects.override-checkout | 18:13 |
| fungi | "This value is also used to help select which variants of a job to run. If override-checkout is set, then Zuul will use this value instead of the branch of the item being tested when collecting any jobs to run which are defined in this project." | 18:13 |
| sassyn | fungi thank u | 18:15 |
| sassyn | I will check this out | 18:15 |
| sassyn | add one more beer to the bill :-) | 18:15 |
| sassyn | and I remove the Zuul branch staging | 18:16 |
| sassyn | let's check it out first | 18:16 |
| sassyn | now it is single branch | 18:16 |
| fungi | sassyn: also in this case, pipeline.debug would have reported those decisions in a comment on that change, so would have been an alternative to digging in the scheduler debug log | 18:23 |
| *** jangutter has quit IRC | 19:03 | |
| *** jangutter has joined #zuul | 19:04 | |
| *** cloudnull7 has joined #zuul | 19:13 | |
| *** cloudnull has quit IRC | 19:13 | |
| *** cloudnull7 is now known as cloudnull | 19:13 | |
| *** cloudnull has quit IRC | 20:01 | |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: Gitlab: raise MergeFailure exception to retry a failing merge https://review.opendev.org/c/zuul/zuul/+/777169 | 23:08 |
| *** ikhan has quit IRC | 23:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!