| opendevreview | Slawek Kaplonski proposed openstack/project-config master: Remove rtd_secret from the trigger-readthedocs-webhook job https://review.opendev.org/c/openstack/project-config/+/933396 | 08:33 |
|---|---|---|
| opendevreview | Slawek Kaplonski proposed openstack/project-config master: Remove rtd_secret from the trigger-readthedocs-webhook job https://review.opendev.org/c/openstack/project-config/+/933396 | 08:35 |
| opendevreview | Slawek Kaplonski proposed openstack/project-config master: DNM Just test of the new config of the trigger-readthedocs-webhook job https://review.opendev.org/c/openstack/project-config/+/933397 | 08:35 |
| opendevreview | Slawek Kaplonski proposed openstack/project-config master: Remove rtd_secret from the trigger-readthedocs-webhook job https://review.opendev.org/c/openstack/project-config/+/933396 | 09:17 |
| opendevreview | Slawek Kaplonski proposed openstack/project-config master: DNM Just test of the new config of the trigger-readthedocs-webhook job https://review.opendev.org/c/openstack/project-config/+/933397 | 09:17 |
| *** __ministry is now known as Guest7436 | 16:26 | |
| clarkb | sean-k-mooney: the reason I don't think that zuul abort behavior for direct git dependencies has changes is that zuul can't merge the child changes without implicitly including the parent which have now failed | 17:11 |
| clarkb | the only thing I can think of is that maybe at some point the jobs were allowed to run to completion but then we marked it as a failure? but it would've always been marked as a failure | 17:11 |
| sean-k-mooney | what i was refering to was the delta between check and gate | 17:12 |
| sean-k-mooney | in check if a child patch fails but the combineind second patch passes all ci job then it gets +1 and the child ahs -1 | 17:12 |
| sean-k-mooney | because of the pipeline type | 17:12 |
| clarkb | ah yes that is true | 17:12 |
| sean-k-mooney | so wehn we have a large series we usully choose a sane brakpoint, queue up abunch of patches with +2w excptin the bottom patch and then send them in one go by adding +w to the bottome | 17:14 |
| clarkb | and the reason is to avoid unnecessarily resetting a prior Verified+1 | 17:15 |
| clarkb | because if you enqueue to the gate and you fail or any ahead of you fail you get a Verified-2 | 17:15 |
| sean-k-mooney | if your lucky all or most of them will merge and the rest will get -v form zuul based on teh gate run | 17:15 |
| sean-k-mooney | ya | 17:15 |
| clarkb | ok I understand better now. THanks | 17:15 |
| sean-k-mooney | so we can get 10 patches with green check, +2w the 9 latter ones and build up the chain. and when we are happy to merge that block of changes we +w the base patch and they all go to the gate | 17:16 |
| clarkb | Even if we don't vote -2 we've already cleared the vote on entry to the gate here: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L92-L94 and reentry requires a +1 or +2 here: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L80 | 17:17 |
| sean-k-mooney | yep we reset it when the buidl starts | 17:17 |
| sean-k-mooney | without doing that when we recheck it actully enques into both | 17:17 |
| clarkb | ya so mechanically the process of entering the gate is what will force you back into check if you don't merge | 17:17 |
| sean-k-mooney | i.e. if you remove https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L94 | 17:18 |
| sean-k-mooney | it will act non intuitively | 17:18 |
| clarkb | right because you'd still have the old +1 | 17:18 |
| sean-k-mooney | to be fair the way we configure it with the success and failure conditions | 17:18 |
| sean-k-mooney | also will override it | 17:19 |
| sean-k-mooney | but i belie you can have other states in zuul | 17:19 |
| sean-k-mooney | like perhaps a differt action for timeout | 17:19 |
| sean-k-mooney | ok not time out but merge-conflict https://zuul-ci.org/docs/zuul/latest/config/pipeline.html#attr-pipeline.merge-conflict | 17:20 |
| clarkb | ya there are several all in a list at and below | 17:21 |
| clarkb | er at and below https://zuul-ci.org/docs/zuul/latest/config/pipeline.html#attr-pipeline.success | 17:21 |
| sean-k-mooney | if i recall check is an independent pipeline gate is dependen and promote/post are supercedent | 17:22 |
| sean-k-mooney | i always have to lookup the details fo those when i try to tell the later two apart | 17:22 |
| clarkb | yes that is correct looking at the config now | 17:22 |
| sean-k-mooney | supercedent is an optimisation of independent | 17:23 |
| sean-k-mooney | where newer jobs can superced the older one | 17:23 |
| sean-k-mooney | i.e. publishing a doc update | 17:23 |
| sean-k-mooney | i.e. you dont need to publish on every commit just the most recent | 17:24 |
| clarkb | correct if three things merge at the same time only the first and third will run jobs | 17:25 |
| sean-k-mooney | its almost as if this was designed to scale well :) | 17:26 |
| clarkb | I think we can optimize out the first as well, but the way it works it enqueues the first one first then the second one while the first runs then the third one evicts the second one before the second runs | 17:26 |
| clarkb | and with a distributed system getting the removal of the first correct is probably more trouble than it is worth | 17:26 |
| sean-k-mooney | the first will be killed when the second is encued | 17:26 |
| clarkb | no once the jobs start running on supercedent I believe they are allowed to finish | 17:27 |
| sean-k-mooney | oh ok | 17:27 |
| sean-k-mooney | i tough they got prememted but thats genreally ok | 17:27 |
| clarkb | so its only items that are waiting to start jobs that get replcaed in the supercedent pipeline | 17:27 |
| clarkb | I think the concern is if you do that you could interrupt some sort of publication process halfway and break the publication | 17:28 |
| sean-k-mooney | well the fact that it groups per repo makes that safe | 17:28 |
| clarkb | so its best to finish once started | 17:28 |
| sean-k-mooney | ya i can see that | 17:28 |
| sean-k-mooney | you dont what a half uploaded tarbal | 17:28 |
| clarkb | ya or half your documentation files to be updated and the other half not | 17:28 |
| sean-k-mooney | so the regression i was refering to was the eleary exit thing | 17:29 |
| sean-k-mooney | that has some not nice behivor in both check and gate | 17:29 |
| clarkb | ya but that should be fixed now | 17:30 |
| sean-k-mooney | hopefully i have not seen it acting strange in a while | 17:30 |
| clarkb | ya I mean I wrote a fix for it and that included a test so we should prevent regressions | 17:31 |
| sean-k-mooney | im 50/50 on if the new zuul ui is a good thing or not however | 17:31 |
| sean-k-mooney | https://zuul.opendev.org/t/openstack/status | 17:31 |
| sean-k-mooney | im not sure i like the new ux bug its "prettier i guess" | 17:32 |
| clarkb | it shouldn't be drastically differen.t I know there are changes but the things people want to accomplish are all still doable but possibly with some small changes to process | 17:32 |
| clarkb | but yes visually it changes due to using more patternfly native objects | 17:32 |
| sean-k-mooney | the one thing that is lost is you cant clik on the tick/x of the card and go to the build set | 17:33 |
| clarkb | sean-k-mooney: you can't jump to this page for example: https://zuul.opendev.org/t/openstack/buildset/54c52b7a767f437aa97b0c4090f71a95 ? | 17:34 |
| sean-k-mooney | exactly | 17:34 |
| sean-k-mooney | that what the tick/x icon that tells you if its currently passing or not used to link to | 17:34 |
| sean-k-mooney | which reduced the load on zuul sicne you were nto pooling the status of all the jobs | 17:35 |
| clarkb | I don't think I realized that. But I'll make a note that people used that functioanlity | 17:35 |
| sean-k-mooney | just the one fo the build set | 17:35 |
| clarkb | it should be possible to add it back | 17:35 |
| sean-k-mooney | so rdo zuul predates the change https://review.rdoproject.org/zuul/status | 17:35 |
| clarkb | sean-k-mooney: if you filter by change you should get the performance improvement fwiw | 17:35 |
| sean-k-mooney | it actully broght you to a diffent view https://review.rdoproject.org/zuul/status/change/2349,137e928e4353d311edec12a596ec4f3c01ae84c0 | 17:36 |
| sean-k-mooney | rather then directly to the buidl set | 17:36 |
| clarkb | ya that should be equivalent to filtering by that change | 17:36 |
| clarkb | in the new ui click on the + magnifying glass and selsect filter by change | 17:36 |
| sean-k-mooney | yep i used to filter by the change before too | 17:36 |
| sean-k-mooney | i just woudl pop it out if i was watching several for well CVE reasons | 17:37 |
| sean-k-mooney | yep i have mostly adapted | 17:37 |
| sean-k-mooney | just muscle memory | 17:37 |
| clarkb | got it so having it open in a new tab/window is maybe the useful part of the process | 17:37 |
| clarkb | which the filter by change magnifying glass window does not appear to support/enable at least not in firefox | 17:37 |
| sean-k-mooney | yep if im debugging someint ill keep the live console open | 17:38 |
| sean-k-mooney | if i am just seeing do i need to recheck this bacasuse reaosn ill keep the full view open | 17:38 |
| * clarkb writes a note | 17:38 | |
| sean-k-mooney | over all the new ui is better | 17:38 |
| sean-k-mooney | the fact it supprot regexs/wildcards is very nice | 17:39 |
| sean-k-mooney | i.e. project *watcher* | 17:39 |
| sean-k-mooney | like this https://zuul.openstack.org/status?project=*neutron* | 17:40 |
| sean-k-mooney | its also intuitivly does the right thing | 17:40 |
| sean-k-mooney | it ORs repeated parmeter and ANDs diffent ones | 17:40 |
| sean-k-mooney | i.e. you can repeate project and set piple=check | 17:41 |
| sean-k-mooney | *pipeline=check | 17:41 |
| sean-k-mooney | so if you want to be fancy you can. before however the earch filed just work for project or job or change id so you didnt have to sepect what to match on first | 17:41 |
| sean-k-mooney | so we got complex queires and lost simpel ones | 17:42 |
| clarkb | ya you can also filter by multiple changes and see the mall on the same pane | 17:42 |
| clarkb | problem is as soon as you filter by one you lose all the context to filter by the others | 17:42 |
| clarkb | which makes your earlier use case more difficult but still possible. | 17:42 |
| sean-k-mooney | yep as i said its mainly muscel memory that i need to fix | 17:43 |
| sean-k-mooney | i am not used to thinking about seting it to project or change | 17:43 |
| sean-k-mooney | i just type the "gerrit number" or "nova" and hit enter | 17:44 |
| sean-k-mooney | the former works because it default to change the later does not but its easy to fix | 17:44 |
| sean-k-mooney | is the magnifying glass even newer | 17:45 |
| sean-k-mooney | i dont recall seeing it the last time i used this | 17:45 |
| sean-k-mooney | it does make some things faster | 17:46 |
| clarkb | the magnifying glass came with the ui update. Its just easy to miss I guess if you aren't looking for it | 17:46 |
| sean-k-mooney | ack | 17:47 |
| clarkb | the problem with having established users with habits :) I suspect that entirely new users would find it more intuitive | 17:47 |
| sean-k-mooney | ya i was thinking the same | 17:47 |
| sean-k-mooney | like new uesrs are proably not going to find the change number for the first patch in a 10 patch series so that you can see all jobs that include it and as a result see the full series | 17:48 |
| sean-k-mooney | like this https://zuul.openstack.org/status?change=703667 | 17:48 |
| clarkb | ya thats something you probably discover accidentally the first time then use it to your advantage | 17:49 |
| sean-k-mooney | well a new user might expect to be able to take the top patch instead of teh bottom to do that | 17:50 |
| sean-k-mooney | but ya thats always the probelm with users :) | 17:50 |
| clarkb | sean-k-mooney corvus expressed and interest in discussion this further but its the weekend for you at the end of the ptg so maybe we can pick it up monday | 18:49 |
| sean-k-mooney | sure. im curerntly reading a proposal for solar power from a company that did a suervay today. im non matix to by the way so i can chat to them on tuseday (monday is a public holiday) | 18:52 |
| sean-k-mooney | to be clear im stilly very happy we are using zuul over prow or jenkins | 18:53 |
| sean-k-mooney | i have had to interact with both for the years and zuul is still a better fit IMHO and has a better gui at least for my usecases/interaction | 18:53 |
| clarkb | that is great to hear. Sorry I popped out for lunch and am only just now returning. Enjoy the three day weekend | 20:08 |
| *** elodilles is now known as elodilles_pto | 20:28 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!