| *** zenkuro has quit IRC | 01:26 | |
| *** sanjayu_ has joined #zuul | 01:55 | |
| *** sanjayu_ has quit IRC | 03:17 | |
| *** evrardjp has quit IRC | 04:33 | |
| *** evrardjp has joined #zuul | 04:33 | |
| *** vishalmanchanda has joined #zuul | 04:45 | |
| openstackgerrit | Ian Wienand proposed zuul/zuul master: web: PF4 minor rework of log viewer page https://review.opendev.org/751140 | 04:49 |
|---|---|---|
| *** wxy has quit IRC | 05:50 | |
| *** jfoufas1 has joined #zuul | 05:59 | |
| *** mach1na has joined #zuul | 06:09 | |
| *** sanjayu_ has joined #zuul | 06:27 | |
| *** hashar has joined #zuul | 06:40 | |
| *** wxy has joined #zuul | 07:06 | |
| *** jpena|off is now known as jpena | 07:22 | |
| *** jcapitao has joined #zuul | 07:29 | |
| openstackgerrit | Pierre-Louis Bonicoli proposed zuul/zuul-jobs master: default test_command: don't use a shell builtin https://review.opendev.org/751659 | 07:53 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Rework quick-start and prepare for other tutorials https://review.opendev.org/732066 | 08:09 |
| *** tosky has joined #zuul | 08:27 | |
| *** nils has joined #zuul | 08:40 | |
| *** saneax has joined #zuul | 08:45 | |
| openstackgerrit | Dmitriy Rabotyagov (noonedeadpunk) proposed zuul/zuul-jobs master: Add support to use stow for ensure-python https://review.opendev.org/751611 | 08:46 |
| *** sanjayu_ has quit IRC | 08:46 | |
| openstackgerrit | Simon Westphahl proposed zuul/zuul master: Offload repo reset during merge https://review.opendev.org/751673 | 09:02 |
| openstackgerrit | Pierre-Louis Bonicoli proposed zuul/zuul-jobs master: default test_command: don't use a shell builtin https://review.opendev.org/751659 | 09:06 |
| *** sshnaidm|pto is now known as sshnaidm | 09:10 | |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Rework quick-start and prepare for other tutorials https://review.opendev.org/732066 | 09:17 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Don't match branch protection rule patterns locally https://review.opendev.org/751686 | 09:26 |
| *** wuchunyang has joined #zuul | 09:38 | |
| *** jfoufas1 has quit IRC | 09:44 | |
| *** holser has joined #zuul | 09:47 | |
| *** jfoufas1 has joined #zuul | 09:56 | |
| *** zenkuro has joined #zuul | 10:12 | |
| *** wuchunyang has quit IRC | 10:15 | |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Add "gate your first patch" https://review.opendev.org/732067 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Add "Use zuul jobs" https://review.opendev.org/732068 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Add "gate pipeline" https://review.opendev.org/732069 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Add "job secrets" https://review.opendev.org/732070 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: tutorial: Add "job dependencies" https://review.opendev.org/732071 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: Rename quick-start to zuul-tutorial-quick-start https://review.opendev.org/737656 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: [DNM] TEST run zuul tutorials to test stream+callback (+ zuul-jobs change) https://review.opendev.org/735477 | 10:30 |
| openstackgerrit | Guillaume Chauvel proposed zuul/zuul master: [DNM] Test: run multiple tutorials ('job dependencies' 2 times) https://review.opendev.org/741558 | 10:30 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 10:33 |
| *** jcapitao is now known as jcapitao_lunch | 10:34 | |
| *** saneax has quit IRC | 10:34 | |
| *** saneax has joined #zuul | 10:36 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: [WIP]Add zuul-client to requirements https://review.opendev.org/750196 | 10:47 |
| *** jfoufas1 has quit IRC | 10:56 | |
| *** mach1na has quit IRC | 11:09 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Don't match branch protection rule patterns locally https://review.opendev.org/751686 | 11:21 |
| *** jpena is now known as jpena|lunch | 11:31 | |
| *** bschanzel has quit IRC | 11:36 | |
| *** bschanzel has joined #zuul | 11:37 | |
| *** mach1na has joined #zuul | 11:40 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 11:41 |
| *** holser has quit IRC | 11:47 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 11:47 |
| *** rfolco has joined #zuul | 11:55 | |
| *** rfolco is now known as rfolco|ruck | 11:55 | |
| *** bhavikdbavishi has joined #zuul | 11:57 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 11:58 |
| *** jcapitao_lunch is now known as jcapitao | 11:59 | |
| *** mach1na has quit IRC | 12:00 | |
| *** mach1na has joined #zuul | 12:01 | |
| *** holser has joined #zuul | 12:04 | |
| *** Goneri has joined #zuul | 12:11 | |
| *** rlandy has joined #zuul | 12:14 | |
| felixedel | zuul-maint: Could we get another review on https://review.opendev.org/#/c/750875/ and its parents? Would be helpful to get those changes merged to finally fix the scrolling issues (and get back the improved build page :D ). | 12:16 |
| *** saneax has quit IRC | 12:20 | |
| *** saneax has joined #zuul | 12:20 | |
| *** jpena|lunch is now known as jpena | 12:28 | |
| *** vishalmanchanda has quit IRC | 12:28 | |
| openstackgerrit | Felix Edel proposed zuul/zuul master: Revert "web: restore scrollbars and scroll behaviour" https://review.opendev.org/750361 | 12:50 |
| openstackgerrit | Felix Edel proposed zuul/zuul master: Revert "Revert PF4 build page" https://review.opendev.org/750365 | 12:50 |
| openstackgerrit | Felix Edel proposed zuul/zuul master: Use Modal to show config errors and fix scrolling https://review.opendev.org/750322 | 12:50 |
| openstackgerrit | Felix Edel proposed zuul/zuul master: web: Fix error modal contents https://review.opendev.org/744095 | 12:50 |
| openstackgerrit | Felix Edel proposed zuul/zuul master: UI: Wrap lines on Logfile page https://review.opendev.org/750875 | 12:50 |
| *** irclogbot_0 has quit IRC | 13:19 | |
| *** irclogbot_2 has joined #zuul | 13:26 | |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 13:30 |
| *** bhavikdbavishi has quit IRC | 13:37 | |
| *** sshnaidm is now known as sshnaidm|afk | 14:07 | |
| *** hashar has quit IRC | 14:14 | |
| *** ianychoi has joined #zuul | 15:24 | |
| *** mach1na has quit IRC | 15:32 | |
| tobiash | zuul-maint: I have a bunch of github improvements (request optimization, better testing and most notably handling review requirements when enqueing into gates): https://review.opendev.org/751686 and parents | 15:37 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 15:40 |
| mhu | hello, I am trying to mimic the nodepool-zuul-functional job for zuul-client with change ^ but I keep hitting timeouts at the end of the build, for example https://zuul.opendev.org/t/zuul/build/84280cb7ed024dc7a2fb80ea077e5ef6 | 15:43 |
| mhu | Any idea why? | 15:43 |
| clarkb | tobiash: couple of questions on the end of that stack | 15:51 |
| clarkb | mhu: zuul's unittest jobs have timeouts set to 80 minutes https://opendev.org/zuul/zuul/src/branch/master/.zuul.yaml#L252 but yours is only 60 minutes when running the same tests | 15:55 |
| clarkb | mhu: I think you're just hitting a known limit there? | 15:55 |
| mhu | clarkb, the timeout seems to happen in the post phase, would that fit? | 15:56 |
| tobiash | clarkb: thanks, responded | 15:56 |
| clarkb | mhu: it happens during the run playbook https://zuul.opendev.org/t/zuul/build/84280cb7ed024dc7a2fb80ea077e5ef6/log/job-output.txt#1690 | 15:57 |
| mhu | gotcha, didn't see this one | 15:58 |
| tobiash | tristanC: was did you not +3 https://review.opendev.org/744194 on purpose? | 15:58 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Add cross testing with Zuul https://review.opendev.org/751264 | 15:58 |
| tristanC | tobiash: yep, still going through the stack | 15:59 |
| tobiash | tristanC: ok, thanks | 16:00 |
| mhu | fungi, I noticed the packaging for zuul-client had some errors, this should fix them: https://review.opendev.org/#/c/751576/ | 16:06 |
| fungi | oh, excellent, thanks... taking a look now | 16:07 |
| tobiash | mhu: so this adds the zuulclient python package to the wheel zuul-client right? | 16:08 |
| mhu | tobiash, it should yes | 16:08 |
| tobiash | k, I was a little bit confused about zuulclient vs zuul-client :D | 16:09 |
| mhu | pip install zuul-client -> import zuulclient | 16:09 |
| mhu | except that the current zuul-client on pypi is broken | 16:10 |
| *** jcapitao has quit IRC | 16:11 | |
| tobiash | clarkb: it would be great if you could put the memleak fixes to your review list as well: https://review.opendev.org/#/q/status:open+project:zuul/zuul+branch:master+topic:memleak-fixes | 16:13 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul-client master: Make default config files location a class attribute https://review.opendev.org/751291 | 16:24 |
| *** armstrongs has joined #zuul | 16:30 | |
| *** jpena is now known as jpena|off | 16:31 | |
| clarkb | tobiash: working through those next. Have some beginning of school year stuff now so may be a bit | 16:40 |
| *** armstrongs has quit IRC | 16:40 | |
| tobiash | thanks | 16:40 |
| openstackgerrit | Merged zuul/zuul-client master: Fix empty package, missing requirement https://review.opendev.org/751576 | 16:48 |
| *** hamalq has joined #zuul | 16:53 | |
| clarkb | tobiash: for https://review.opendev.org/#/c/751171/1/zuul/scheduler.py as noted in the commit message we should eventually process the exception and clear it out normally. Do you know if we're leaking those long term? | 16:57 |
| clarkb | I'm curious if this is a persistent memory leak or an optimization | 16:57 |
| tobiash | clarkb: https://review.opendev.org/751172 fixes the long term leaking. However I thought it would be safer to also clear out the exception (especially since printing the stack trace doesn't need the local variables). | 17:00 |
| *** sassyn has joined #zuul | 17:04 | |
| *** vishalmanchanda has joined #zuul | 17:05 | |
| sassyn | Hi everyone | 17:05 |
| sassyn | Again it is me - with my stupid questions :-) | 17:06 |
| sassyn | this is a quick one: if I have a repo and in the repo I have the branch master and the branch zuul-config. in each branch there are .zuul.yaml file. In the master there is a job X and in the zuul-branch there is a job Y. I'm sending patches to gerrit into the zuul-branch and expecting to see the job Y running, however I'm getting the job X. | 17:08 |
| sassyn | Who wins in such a config? | 17:08 |
| corvus | sassyn: it depends on the project stanza. you can see how zuul decided to run a job by looking at the _inheritance_path variable in the inventory.yaml file in the log files for the build | 17:10 |
| openstackgerrit | Merged zuul/zuul master: Move reports from FakeGithubConnection to github data https://review.opendev.org/745107 | 17:11 |
| sassyn | corvus: where can I find the inventory.yaml? | 17:11 |
| corvus | sassyn: it should be saved with the log files for the build | 17:12 |
| corvus | sassyn: here's an example: https://zuul.opendev.org/t/zuul/build/aed732cd208b4e4285866d817d28b390/log/zuul-info/inventory.yaml#38 | 17:12 |
| corvus | sassyn: and if you look at the bottom entry, it points to line 224 of the .zuul.yaml file on the master branch of the zuul project: https://opendev.org/zuul/zuul/src/branch/master/.zuul.yaml#L224 | 17:14 |
| corvus | sassyn: that's the project stanza that zuul used to decide to run the job | 17:14 |
| sassyn | https://pasteboard.co/Jr4tY89.png | 17:15 |
| sassyn | I have something line this | 17:15 |
| corvus | sassyn: click "logs" | 17:15 |
| sassyn | Build result cdf0479a647a443f9d49685efbd80d0a | 17:16 |
| corvus | sassyn: should look like this: https://zuul.opendev.org/t/zuul/build/aed732cd208b4e4285866d817d28b390/logs | 17:16 |
| sassyn | https://pasteboard.co/Jr4uG97.png | 17:17 |
| sassyn | I don't seems to have it | 17:17 |
| sassyn | https://pasteboard.co/Jr4v7Tj.png | 17:18 |
| *** holser has quit IRC | 17:18 | |
| corvus | sassyn: add this role to your base job: https://zuul-ci.org/docs/zuul-jobs/general-roles.html#role-log-inventory | 17:19 |
| mhu | fungi, corvus before we re-tag zuul-client to fix the pypi package, I'd like to wait for https://review.opendev.org/751264 and https://review.opendev.org/751291 to land first | 17:19 |
| sassyn | u mean add it to the trusted project | 17:19 |
| mhu | unless you're fine with doing two tags | 17:19 |
| corvus | sassyn: yes, the base job is usually defined in a trusted project. we recommend adding that to the base job's pre-playbook like this: https://opendev.org/zuul/zuul-base-jobs/src/branch/master/playbooks/base/pre.yaml | 17:20 |
| sassyn | ok | 17:20 |
| sassyn | post-run: | 17:20 |
| fungi | mhu: makes sense, i have no objection. it's not actually used for anything yet so i'm good with whatever pace is comfortable for you there | 17:21 |
| corvus | mhu, fungi: 0.0.1 has already been pushed | 17:22 |
| corvus | mhu, fungi: https://pypi.org/project/zuul-client/ | 17:23 |
| fungi | corvus: i assumed he meant the next tag | 17:23 |
| tobiash | 0.0.2 probably | 17:23 |
| fungi | with the recent wheel fix | 17:23 |
| corvus | i assumed otherwise since he said "fix the pypi package" | 17:24 |
| fungi | 751576 (which fixes the pypi package) only merged half an hour ago | 17:25 |
| corvus | okay. 751259 also fixed pypi | 17:25 |
| fungi | yup ;) | 17:25 |
| corvus | fungi: i agree that your interpretation of the ambiguous statement from mhu is probably correct. | 17:25 |
| corvus | mhu: i don't think we're in a rush; the only time-sensitive thing is to lock in registration of the package on pypi, and that's done | 17:27 |
| corvus | mhu: take all the time you want before we release the next version | 17:27 |
| sassyn | doing it now | 17:31 |
| mhu | corvus, yes I meant 0.0.2 | 17:32 |
| sassyn | corvus: i have something like this | 17:33 |
| sassyn | vars: | 17:33 |
| sassyn | branch: zuul-branch | 17:33 |
| mhu | we will need to release a 0.0.2 anyway before working on zuul integration: it was started in https://review.opendev.org/#/c/750196/ but builds fail because the pip package is broken | 17:33 |
| fungi | mhu: you could probably make a temporary version of that job which uses zuul-client as a required project and installs it from current source, which would also make it possible to do cross-project deps between the changes to prove out your design | 17:41 |
| sassyn | corvus: I understand the output | 17:45 |
| sassyn | but don't understand why it is like this | 17:46 |
| sassyn | hi fungi | 17:46 |
| sassyn | Thanks again for the help the other day | 17:46 |
| sassyn | :-) | 17:46 |
| fungi | sassyn: you're welcome. this seems like a continuation of our earlier conversation, but you've made some progress i gues | 17:49 |
| fungi | s | 17:49 |
| sassyn | true. I have now in the trusted project base jobs which are abstract and I'm have in a untrusted project a job which get then from the base and them as well the specific job in the untrusted project | 17:51 |
| sassyn | I just don't get the way it work with multi branch | 17:52 |
| sassyn | corvus help me - but I don't understand the output | 17:52 |
| corvus | sassyn: perhaps you could paste all of the relevant configuration to a pastebin service for someone to look at? | 17:52 |
| sassyn | sure | 17:53 |
| *** hamalq has quit IRC | 17:53 | |
| *** hamalq has joined #zuul | 17:53 | |
| *** holser has joined #zuul | 17:57 | |
| sassyn | corvus: https://pastebin.pl/view/b1445888 | 17:57 |
| sassyn | this is the trusted project | 17:57 |
| sassyn | https://pastebin.pl/view/c8433a61 | 17:59 |
| sassyn | this is for the untrusted project | 17:59 |
| sassyn | I would expect that if I do a patch in the branch master job X will run, and if I do patch in branch zuul-branch job Y will run. But in both cases job X is only the one that runs. | 18:01 |
| corvus | sassyn: your paste says you want to run the job "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY" but i don't see a job "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY" defined | 18:01 |
| sassyn | https://i.pinimg.com/564x/2b/30/e9/2b30e9476db1ec0823c7142e0e5ef75a.jpg | 18:03 |
| sassyn | This is what I am | 18:03 |
| sassyn | works perfect!!! | 18:14 |
| sassyn | thank u | 18:14 |
| corvus | sometimes you need a second pair of eyes :) | 18:14 |
| sassyn | u have magic eyes | 18:15 |
| sassyn | one more question, job X and job Y run the pre and post jobs of the base. how can I make that Job Y will not run it again, just X+Y jobs | 18:15 |
| sassyn | I mean - pre jobs + X + Y + post jobs | 18:16 |
| sassyn | and not pre jobs + X + post jobs pre jobs + Y + post jobs | 18:16 |
| corvus | sassyn: there aren't pre jobs and post jobs, there are pre-playbooks and post playbooks. | 18:16 |
| corvus | sassyn: you may want to look into job dependencies | 18:17 |
| sassyn | OK | 18:17 |
| corvus | sassyn: and you can also have multiple base jobs | 18:17 |
| corvus | sassyn: but generally, a base job should do the work that every job needs to do | 18:17 |
| sassyn | this is what fungi told me - but know I understand it better | 18:17 |
| sassyn | now* | 18:18 |
| corvus | sassyn: with job dependencies, you can have Y only run after X completes, or run A, then have X and Y both run after A completes. or similar constructions. | 18:18 |
| corvus | sassyn: you can also run A, have it pause, then run X and Y, and have A resume when both X and Y complete | 18:19 |
| sassyn | super! | 18:19 |
| corvus | lots of options :) | 18:19 |
| sassyn | it is amazing amazing system | 18:19 |
| sassyn | jenkis is a kid compare to it | 18:19 |
| sassyn | amazing! | 18:19 |
| sassyn | only the entry level to get it takes time | 18:19 |
| corvus | we're working on making it easier :) | 18:20 |
| sassyn | may I ask who you are working for? | 18:20 |
| sassyn | redhat? | 18:20 |
| sassyn | openstack - I do i get such a cool job :-) | 18:20 |
| sassyn | who* | 18:21 |
| sassyn | how* | 18:21 |
| corvus | sassyn: a lot of folks contribute to zuul part-time while working on other projects (eg, running a zuul internally) | 18:22 |
| fungi | for example, i contribute to zuul and help run the zuul deployment for the opendev collaboratory; my time doing that is funded by the openstack foundation, but i wouldn't say i necessarily work *for* them, i'm working for the projects to which i'm contributing | 18:25 |
| fungi | (though i am very thankful to the osf for providing the means for me to be able to do those things) | 18:26 |
| fungi | sassyn: while not the only place to find such jobs, the osf maintains a jobs board here for companies to list jobs relevant to represented projects: https://www.openstack.org/community/jobs/ | 18:29 |
| fungi | many of them would probably be willing to consider also having that person help by contributing zuul some of the time | 18:29 |
| fungi | it worth discussing with them, at the very least | 18:30 |
| *** mgoddard has quit IRC | 18:34 | |
| *** mgoddard has joined #zuul | 18:41 | |
| openstackgerrit | Merged zuul/zuul master: Fix memleak on zk session loss https://review.opendev.org/751170 | 18:44 |
| sassyn | corvus ping | 18:57 |
| sassyn | I still fighting the job X and Y. | 18:58 |
| openstackgerrit | Merged zuul/zuul master: Clear traceback before attaching exception to event https://review.opendev.org/751171 | 18:59 |
| openstackgerrit | Merged zuul/zuul master: Remove source_event from Change objects https://review.opendev.org/751172 | 18:59 |
| openstackgerrit | Merged zuul/zuul master: Offload repo reset during merge https://review.opendev.org/751673 | 18:59 |
| sassyn | repo name X, two branch. Branch Master and Branch zuul-branch. both have .zuul.yaml. master configure to run job X and zuul-branch is configure to run job Y. when push patch to master- job X is running. when pushing path to zuul-branch also job X is running. why? | 19:00 |
| fungi | sassyn: the master branch configuration applies to all branches. you may need to set a branch filter on the master branch job to say it only applies to the master branch | 19:03 |
| sassyn | by just setting the branch: master in the .zuul.yaml on the master branch? | 19:04 |
| corvus | fungi: that's only true for jobs defined in branchless repos | 19:06 |
| corvus | that's why i was hoping to get a full configuration from sassyn to see where jobs X and Y are defined | 19:06 |
| sassyn | well I'm confused | 19:07 |
| sassyn | the configuration is the same as i paste bin | 19:08 |
| sassyn | only after configure the Y job | 19:08 |
| sassyn | i did it again but it doesn't work | 19:08 |
| corvus | sassyn: if we talk through all of the potential ways your system could be configured, it will take a while. i would recommend one of the following options: 1) read the entire documentation about configuration; 2) add the log-inventory role so you can see what zuul is doing; 3) paste your configuration so i can look at it and i may be able to spot what's confusing you | 19:09 |
| sassyn | corvus thank u. I read and I'm doing my best here | 19:10 |
| sassyn | https://pastebin.pl/view/b1445888 is the trusted | 19:10 |
| fungi | corvus: oh, right, i keep forgetting we changed the default branch matcher for branched repos early in v3 | 19:10 |
| corvus | fungi: yeah, that was a really early design | 19:11 |
| sassyn | https://pastebin.pl/view/6871fa4e | 19:12 |
| sassyn | this is the untrusted project | 19:12 |
| fungi | so yes, unless the master branch job in that repo also had an explicit branch matcher for zuul-branch, it shouldn't have been triggered on a zuul-branch event | 19:12 |
| corvus | sassyn: from that, i would expect both testjob and testjob2 to run when you upload a change to zuul-branch | 19:14 |
| corvus | sassyn: what do you want to happen? | 19:14 |
| sassyn | both testjob and testjob2 to run when you upload a change to zuul-branch | 19:14 |
| corvus | sassyn: what does happen? | 19:14 |
| sassyn | only testjob is running | 19:15 |
| sassyn | and I also now deleted the .zuul.yaml in the master branch | 19:15 |
| sassyn | push patch to zuul-branch | 19:16 |
| sassyn | and - '<Job base branches: None source: zuul-config/zuul.d/jobs.yaml@master#1>' | 19:16 |
| sassyn | still no testjobs2 | 19:17 |
| corvus | sassyn: it's possible zuul doesn't know about zuul-branch. are you using gerrit, github or something else? | 19:18 |
| sassyn | gerrit | 19:18 |
| sassyn | i did deleted the branch | 19:18 |
| sassyn | and recreated it | 19:18 |
| sassyn | is this is a problem? | 19:18 |
| corvus | sassyn: you may want to restart the scheduler and verify that it loads the configuration from zuul-branch | 19:18 |
| corvus | sassyn: theoretically that should not be a problem, but something may have gone wrong | 19:18 |
| sassyn | the zuul-scheduler.service? | 19:19 |
| corvus | sassyn: check the debug log when you restart the scheduler to confirm where it loads its config from | 19:19 |
| corvus | yep | 19:19 |
| sassyn | 2020-09-15 01:19:17,673 INFO zuul.TenantParser: Loading configuration from ZuulTest/.zuul.yaml@zuul-branch | 19:19 |
| fungi | i suppose zuul could have somehow missed the ref-updated event from when the configuration was pushed into the zuul-branch branch earlier and not loaded it at that time? | 19:20 |
| sassyn | restarted fix the issue | 19:21 |
| sassyn | fungi, I don't know | 19:21 |
| sassyn | I can look in the logs | 19:21 |
| fungi | though that doesn't make sense, because subsequent changes for that branch would have required it so checkout the current state of the branch and evaluate configuration in it, right? | 19:22 |
| fungi | er, required it to checkout | 19:22 |
| corvus | fungi: only changes that touched .zuul.yaml would do that | 19:22 |
| fungi | ahh, okay | 19:23 |
| *** hamalq has quit IRC | 19:32 | |
| *** hamalq has joined #zuul | 19:33 | |
| *** vishalmanchanda has quit IRC | 19:44 | |
| sassyn | corvus fungi everything work now fine! | 19:44 |
| corvus | sassyn: \o/ | 19:45 |
| fungi | oh, excellent | 19:46 |
| fungi | i'm still mildly concerned that zuul didn't notice you added configuration to or updated configuration in that branch before it was restarted | 19:46 |
| *** nils has quit IRC | 19:48 | |
| sassyn | fungi: basically this is what I wanted, to add my already exiting project to zuul as untrusted project , create a new branch, create in this branch the .zuul.yaml file and have zuul to run the job only if commits are come to this branch | 20:03 |
| sassyn | putting the branch on the job is nice, but will be good if I put the .zuul.yaml in the MASTER branch so it can effect all other branch | 20:05 |
| sassyn | do I understand correctly ? | 20:05 |
| fungi | sassyn: yes, if you put the config in the branch of a branched project, it should be used for events related to that branch | 20:06 |
| fungi | this is, in part, designed to support a branching process where if you create a new branch from a branch which already had zuul configuration in it, then job behaviors should diverge properly as the branches themselves diverge and become independent | 20:07 |
| sassyn | OK got it. but if however the zuul.yaml is in the master | 20:08 |
| sassyn | than all branch are applied, even if they don't .zuul.yaml in them | 20:08 |
| sassyn | correct? | 20:08 |
| sassyn | Or I mistaken here? | 20:10 |
| *** nils has joined #zuul | 20:14 | |
| fungi | sassyn: not the case, no. i was the one who was mistaken about that | 20:16 |
| sassyn | ok so now it make sense | 20:16 |
| sassyn | thank u ! | 20:17 |
| fungi | we had done it that way *very* early in the v3 design, and quickly realized that created problems for projects branching their configuration. the sensible thing to so was to use the configuration from the branch itself | 20:17 |
| fungi | er, sensible thing to do | 20:17 |
| sassyn | yep! | 20:17 |
| sassyn | but I think I discover a bug | 20:18 |
| sassyn | repo X, branch A and B. branch A have zuul.yaml, branch B have zuul.yaml. A run job A, B run job B. i delete from brnach B the zuul.yaml and still it run the job | 20:19 |
| sassyn | if I will restart i guess this will solved | 20:19 |
| sassyn | please ignore it | 20:24 |
| sassyn | my mistake | 20:24 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: [DNM] Add zuul-client to requirements https://review.opendev.org/750196 | 20:26 |
| sassyn | what will be the logic to use project.<pipeline>.jobs.branch as it says here: https://zuul-ci.org/docs/zuul/reference/project_def.html#attr-project.%3Cpipeline%3E.jobs? | 20:26 |
| fungi | sassyn: that's intended for when you define jobs in one repository which only has a single branch and then use them in another repository which has multiple branches | 20:27 |
| fungi | that's what i was trying to describe over the weekend with the difference between explicit and implied branch matchers | 20:28 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: [DNM] Add zuul-client to requirements https://review.opendev.org/750196 | 20:30 |
| sassyn | so consider the followingL if I have repo X, with branch Y, and on branch Y is the .zuul.yaml, and then I create a new branch from it says branch Z, when I will commit to branch Y an Z in repo X zuul will run on both. if however I would put project.<pipeline>.jobs.branch: Y then even if I will create a new bracnh from Y, zuul will stil run only on | 20:31 |
| sassyn | Y : | 20:31 |
| sassyn | only. and sorry for typo mistakes. | 20:31 |
| clarkb | you can manipulate it to do that sort of thing but we generally recommend against it | 20:33 |
| fungi | i'm not sure i understand. a commit will either be for branch y or branch z, not for both. zuul will run the jobs described in the configuration on the branch which the change targets (or in the change itself if the change modifies that configuration) | 20:33 |
| clarkb | fungi: I read it as config says branch: y in both y and z. Then you push change to z and it doesn't run but would run if you push a change to y | 20:33 |
| fungi | oh, got it. yes i would not try to use explicit branch matchers with configuration in branched repositories | 20:35 |
| sassyn | I just want to make sure that even if u clone from the branch that has the .zuul.yaml (say clone from branch Y that has the zuu.yaml into a new branch Z), zuul will still only run only if patches are going into branch Y. patches to branch Z will be ignored. | 20:37 |
| fungi | either rely on the branches of the repository to separate your configuration on a per-branch basis, or define things in a single branch-repository with explicit branches set on configuration. you can combine those two approaches by using both kinds of repositories (we do a lot of that in opendev) but avoid specifying branches in configuration if that configuration is in a repository with multiple branches | 20:37 |
| fungi | you don't really clone from a branch. you clone a repository and checkout a branch, but it's better to think in terms of the repository itself when it comes to cloning | 20:39 |
| openstackgerrit | Matthieu Huin proposed zuul/zuul master: [DNM] Add zuul-client to requirements https://review.opendev.org/750196 | 20:39 |
| sassyn | " define things in a single branch-repository with explicit branches set on configuration" - can u provide an example ? | 20:42 |
| fungi | sassyn: sure, this repository contains job definitions for things run on changes for other repositories and you'll see lots of "branches" patterns in it: https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/jobs.yaml | 20:45 |
| fungi | the openstack/openstack-zuul-jobs repository only has a master branch, but we use it to contain job definitions for things we want run on changes for other repositories which have branches | 20:46 |
| fungi | so we specify which jobs and which versions of jobs we want to run for changes to what branches of those other repositories | 20:46 |
| fungi | the first job you see there, build-openstack-sphinx-docs, is set to only run if the triggering change's branch matches the pattern ^stable/(ocata|pike|queens|rocky).*$ | 20:47 |
| sassyn | fungi but this is on the job level | 20:49 |
| sassyn | I talking about the project level | 20:50 |
| sassyn | https://zuul-ci.org/docs/zuul/reference/project_def.html#attr-project.%3Cpipeline%3E.jobs | 20:50 |
| sassyn | putting branch on the job will limit the job to run only on the branch configure (per job) | 20:52 |
| fungi | sassyn: oh, yep, in a variant. we do that too: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/projects.yaml#L6743-L6784 | 20:53 |
| fungi | we still keep that configuration in a single-branch repository though | 20:54 |
| sassyn | why? if this is a single branch there is not logic. cause if I have the same zuul.yaml file in branch A and branch B, and I have set the porject.gate.jobs.A.branch:A then A will run only if committed to branch A, and B only if committed to branch B. or what u saying is that I call this job from a multi branch and then I set it on a sinle branch. | 21:01 |
| sassyn | If so now at LAST i understand | 21:01 |
| clarkb | sassyn: if you have a config on each branch that config automatically applies to that branch. Basically its implied to work by default in the way you describe it | 21:03 |
| clarkb | sassyn: but if you want to control that independently from another location perhaps to ensure a job is always run on all repos or something then you can use that branch config option to control it further from that independent location | 21:04 |
| fungi | also useful when you want to have a central location for jobs used by multiple other repositories | 21:04 |
| sassyn | understand! | 21:05 |
| fungi | you can do that in multi-branch repositories if all your branch names in the various repositories match, but if they don't then having a single-branch repository to put the shared configuration in is easier | 21:05 |
| fungi | and in that case, it's useful to be able to specify to which branches some bit of configuration should apply | 21:06 |
| *** rfolco|ruck has quit IRC | 21:12 | |
| *** sassyn has quit IRC | 21:14 | |
| *** sassyn has joined #zuul | 21:17 | |
| sassyn | how can I have in repo X branch A a job from repo Y on branch master | 21:19 |
| sassyn | this I still missing | 21:19 |
| clarkb | the jobs exist within a global namespace for each zuul tenant. That means a job defined in one repo is avaialble to any other repo | 21:22 |
| clarkb | you simply list it ina pipeline config | 21:22 |
| sassyn | so if I have job name X i can't have job name X again | 21:25 |
| clarkb | correct | 21:26 |
| sassyn | thank u | 21:39 |
| sassyn | notice again that I to restart the service | 21:40 |
| sassyn | after changing .zuul.yaml the server still using the old config | 21:40 |
| clarkb | are you changing it through gerrit? | 21:41 |
| clarkb | I wonder if we're missing the events if things are mreged directly rather than through gerrit changes | 21:42 |
| sassyn | no i do it via cli | 21:43 |
| sassyn | git push origin HEAD:refs/for/master | 21:43 |
| clarkb | then you merge the change via gerrit? if so that should create events that zuul notices and updates its configs from | 21:44 |
| sassyn | yep | 21:46 |
| sassyn | via gerrit | 21:46 |
| sassyn | i think i found the core issue | 21:46 |
| sassyn | i used a job name in repo L branch master that come from a specific branch (in repo X branch Y job Z) - zuul didn't knew about it. if I add a job from repo X branch master job M - zuul knows about it in the repo L brnach master | 21:48 |
| sassyn | there is some bug - I'm sure somewhere. can't tell where | 21:48 |
| sassyn | but again this is amazing project! | 21:49 |
| sassyn | WOW! | 21:49 |
| sassyn | so much options | 21:49 |
| openstackgerrit | Merged zuul/zuul master: Remove unneeded api requests when commenting in github https://review.opendev.org/744194 | 21:56 |
| openstackgerrit | Merged zuul/zuul master: Exercise github auth handling in tests https://review.opendev.org/749711 | 21:56 |
| sassyn | is it smart to put the ansible and jobs in the trusted project? or to create a new repo with single branch? | 22:00 |
| sassyn | I'm asking myself where I will put the project templates for example | 22:00 |
| clarkb | sassyn: keeping as much stuff as possible in untrusted areas is useful because it means you can test them in pre merge contexts | 22:00 |
| clarkb | for trusted repos it really should be as minimal as possible ideally | 22:01 |
| sassyn | OK | 22:01 |
| sassyn | understood | 22:01 |
| clarkb | because testing chnages to trusted areas is more difficult | 22:01 |
| sassyn | thank u | 22:01 |
| sassyn | yep | 22:01 |
| *** tosky has quit IRC | 22:33 | |
| sassyn | One more if I may: say I have Repo X, and when doing patches a gate pipeline start where we run the job X. We wait until job X finish and on success and we run Job Y, Z (in parallel? is it possible). Now say I have Repo Y, and when doing gate I want to run job Y. Job Y is configure as required Job X . This is OK, but wouldn't I will get into a | 22:47 |
| sassyn | loop on Repo X? since Repo X run X and then Run Y which need to run X again? | 22:47 |
| fungi | yes, y and z can depend on the success of x, and will run concurrently with each other | 22:49 |
| fungi | i'm not entirely sure i understand the second scenario you're describing | 22:50 |
| sassyn | Consider Job Y as a test of the outcome of Job X. So Job X can be run as a standalone. but Job Y to run need first Job X in order to run by itself. What I want is when commit come to repo X job X is run, and then after r job X Y (in parallel) to test the outcome of job X. But when commit come to repo Y for example., I want to run job X and then | 22:57 |
| sassyn | Job Y. if job Y depend on job X, the on the first case (commit to repo X ) Job A will run , then Job Y which will trigger again Job A and then finaly jfinish with job Y. | 22:57 |
| clarkb | sassyn: you can do that with job dependencies | 23:03 |
| clarkb | I'm looking for a docs link | 23:03 |
| clarkb | sassyn: https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.dependencies is how you order jobs | 23:06 |
| clarkb | https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.requires and https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.provides allow you to express dependencies around resources | 23:06 |
| clarkb | depending on the situation you may use one or the other or both configuration tools | 23:06 |
| fungi | yeah, i think i'm getting confused by there being repos x and y but also jobs x and y... and i'm not sure if there's supposed to be a relationship between the job names and the repo names there | 23:18 |
| fungi | is "job x y" in your scenario the job named y for the repo named x? or are you saying after running job x you want to run job x again at the same time as job y? | 23:19 |
| fungi | and i don't see where "job a" came from | 23:20 |
| sassyn | fungi, I will try it myself first and will get back to u tommorow | 23:29 |
| sassyn | thanks again for all the help | 23:29 |
| sassyn | u 2 clarkb | 23:29 |
| sassyn | have a good evening. | 23:29 |
| fungi | good luck! | 23:30 |
| *** Goneri has quit IRC | 23:53 | |
| *** armstrongs has joined #zuul | 23:55 | |
| *** holser has quit IRC | 23:55 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
