Monday, 2019-07-29

*** jamesmcarthur has joined #zuul00:00
*** jamesmcarthur has quit IRC00:43
*** jamesmcarthur has joined #zuul00:44
*** jamesmcarthur has quit IRC00:49
*** jamesmcarthur has joined #zuul00:53
*** jamesmcarthur has quit IRC01:15
*** igordc has quit IRC01:24
*** jamesmcarthur has joined #zuul01:43
*** rfolco|rover has joined #zuul02:08
*** bhavikdbavishi has joined #zuul02:12
*** rfolco|rover has quit IRC02:16
*** bhavikdbavishi has quit IRC02:21
*** bhavikdbavishi has joined #zuul03:06
*** jamesmcarthur has quit IRC03:21
*** jamesmcarthur has joined #zuul03:22
*** jamesmcarthur has quit IRC03:27
*** jamesmcarthur has joined #zuul03:39
*** jamesmcarthur has quit IRC03:58
*** jamesmcarthur has joined #zuul03:59
*** jamesmcarthur has quit IRC04:04
*** jamesmcarthur has joined #zuul04:07
*** jamesmcarthur has quit IRC04:40
AJaeger_tristanC, mordred , could you review https://review.opendev.org/#/c/672058/ for promstat, please?04:44
*** jamesmcarthur has joined #zuul05:07
*** jamesmcarthur has quit IRC05:14
*** jamesmcarthur has joined #zuul05:40
*** jamesmcarthur has quit IRC05:44
*** raukadah is now known as chandankumar05:46
*** AJaeger_ has quit IRC05:58
*** AJaeger has joined #zuul06:15
*** jamesmcarthur has joined #zuul06:20
*** jamesmcarthur has quit IRC06:25
*** saneax has joined #zuul06:37
*** tosky has joined #zuul07:16
*** jamesmcarthur has joined #zuul07:21
*** jamesmcarthur has quit IRC07:25
*** jpena|off is now known as jpena07:30
*** pcaruana has joined #zuul07:31
*** jangutter has joined #zuul07:38
*** arxcruz|off is now known as arxcruz07:38
*** jamesmcarthur has joined #zuul07:57
*** jamesmcarthur has quit IRC08:02
*** yolanda has joined #zuul08:42
*** panda has quit IRC08:47
*** panda has joined #zuul08:48
*** jamesmcarthur has joined #zuul08:59
*** jamesmcarthur has quit IRC09:03
*** bhavikdbavishi has quit IRC09:23
*** altlogbot_3 has quit IRC09:24
*** altlogbot_2 has joined #zuul09:26
*** jamesmcarthur has joined #zuul09:38
*** jamesmcarthur has quit IRC09:43
mordredAJaeger: done09:46
AJaegerthanks, mordred - and good morning ;)10:38
*** jamesmcarthur has joined #zuul10:39
mordredgood morning!10:44
*** jamesmcarthur has quit IRC10:44
*** saneax has quit IRC10:57
*** jamesmcarthur has joined #zuul11:11
*** jamesmcarthur has quit IRC11:16
*** jamesmcarthur has joined #zuul11:27
*** jamesmcarthur has quit IRC11:36
*** jamesmcarthur has joined #zuul11:37
*** rfolco|rover has joined #zuul11:37
*** rfolco|rover is now known as rfolco|ruck11:37
*** rfolco|ruck is now known as rfolco|rover11:39
*** saneax has joined #zuul11:39
*** jpena is now known as jpena|lunch11:46
*** saneax has quit IRC12:03
*** jamesmcarthur has quit IRC12:05
*** jpena|lunch is now known as jpena12:33
*** rfolco|rover is now known as rfolco|ruck12:47
*** jamesmcarthur has joined #zuul12:49
*** cixx has joined #zuul12:52
cixxhi.12:52
cixxwhy zuul instead of jenkins?12:53
AJaegercixx: did you read https://zuul-ci.org/ and specially https://zuul-ci.org/media/zuul_solution_brief.pdf ?12:59
mordredcorvus: when you're up - it is unclear to me why https://review.opendev.org/#/c/673143 "depends on a change that failed to merge"13:05
*** AshBullock has joined #zuul13:37
*** AshBullock has quit IRC13:48
*** jeliu_ has joined #zuul14:04
openstackgerritJeff Liu proposed zuul/zuul-operator master: use opendev image building system for zuul-operator test  https://review.opendev.org/67302014:15
*** panda is now known as panda|brb14:19
*** olaph has joined #zuul14:20
*** michael-beaver has joined #zuul14:23
*** panda|brb is now known as panda14:25
toskylooking at the fact-subunit-output role, it looks like the name of the output html is hardcoded, which may be a problem if I want to collect multiple subunit files14:34
toskybecause regardless of the zuul_work_dir, they are collected in testr_repository.html file which ends up into zuul.executor.log_root14:34
toskydo I read it correctly? How can I handle such scenario? Adding a new parameter to fetch-subunit-output?14:35
fungithat's how i'd do it, yeah. something like have the parameter take a list and default to a singleton of the existing value so it retains backward-compatibility with current uses14:37
clarkbyou can also combine subunit files14:37
fungiyep, i guess depending on the use case that might be preferable14:38
toskyI see two possible use cases, but that also depends on how subunit2html parses the subunit file14:39
clarkbmordred: for that error you might need to grep the merger logs for why it failed. I had to do similar for smcginnis last week14:39
mordredclarkb: awesome14:40
toskya) the specific use case I'm working on is about cinder jobs returning both tempest and cinderlib functional tests; they have different prefixes, so their result can be combined, I could combine the streams14:40
*** electrofelix has joined #zuul14:40
pabelangerremote:   https://review.opendev.org/673304 Default zuul tenant to use ansible 2.8 for jobs14:40
pabelangerbased on my testing on Friday, I think we can consider doing ^14:40
pabelangerI wasn't able to see any jobs fail under 2.8, but also unsure if I missed any14:41
toskyb) a not-yet-implemented but useful pattern of running multiple times the same tests with slightly different tempest configurations; in that case maybe the different subunit files should be handled differently to make it easier for humans to parse the results14:41
toskybut let me try a parameter :)14:41
clarkbtosky: subunit does timestamp every test run as will as give them a unique identifier iirc. That means it should be safe to combine runs of the same tests14:42
clarkbthey will show up as additional runs of the same tests at different times14:42
toskyoh, I see, interesting14:42
toskyso would it make sense to add a general "merge subunit files, if more are specified" role somewhere in the basic jobs?14:43
clarkbI think so. I want to say the regular tempest jobs already do this because they run tox twice on different sets of jobs14:44
clarkb*different sets of tests. There exists some need for this already14:44
toskyI think that's handled at the tox level14:45
toskyhttps://opendev.org/openstack/tempest/src/branch/master/tox.ini#L10914:45
clarkbyes it already does it, but we could bubble that up into the log handling I bet14:46
*** jank has joined #zuul14:48
toskylet's see: what do you think about an additional parameter for fetch-subunit-output which contains a list of additional paths where to look for additional subunit files, and a bunch of tasks to combine them with the main one (under zuul_work_dir)?14:50
*** jank has quit IRC14:53
clarkbI think that would work14:54
toskyok, let me see if I can produce something that makes sense14:55
*** bhavikdbavishi has joined #zuul15:04
*** bhavikdbavishi1 has joined #zuul15:07
tosky(for the record, subunit2html combines different runs of the same tests together, so they are in the same lines)15:08
clarkbtosky: with  different timestamps though right?15:08
toskyyep15:09
*** bhavikdbavishi has quit IRC15:09
*** bhavikdbavishi1 is now known as bhavikdbavishi15:09
*** jamesmcarthur has quit IRC15:16
*** jamesmcarthur_ has joined #zuul15:16
*** bhavikdbavishi has quit IRC15:37
openstackgerritMerged zuul/zuul-jobs master: Don't try to push images when the build failed  https://review.opendev.org/67314715:38
*** mattw4 has joined #zuul15:50
openstackgerritJeff Liu proposed zuul/zuul-operator master: use opendev image building system for zuul-operator test  https://review.opendev.org/67302015:51
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Use human-readable names for artifact returns  https://review.opendev.org/67238216:06
openstackgerritJames E. Blair proposed zuul/zuul-jobs master: Remove download_artifact_name parameter  https://review.opendev.org/67332716:06
*** mattw4 has quit IRC16:12
openstackgerritMerged zuul/zuul-jobs master: Download-artifact: use the artifact type rather than name  https://review.opendev.org/67255716:14
*** AshBullock has joined #zuul16:16
AshBullockHey guys, I've seen this change https://review.opendev.org/#/c/578557/ Was wondering what the status of getting merged is, we have a use case where we need to trigger based on a tag to master ref, so this would solve this for us16:19
corvusmhu: sorry, caught one more thing on https://review.opendev.org/63631516:20
mhucorvus, no worries at all, it's for the greater good!16:21
openstackgerritJames E. Blair proposed zuul/zuul-operator master: DNM: test images  https://review.opendev.org/67333316:26
fungiAshBullock: i think we were mostly looking for more feedback from zuul users on whether or not they considered it a good idea (seeing as how it's basically papering over inconvenient realities of git's data model for the sake of convenience)16:29
*** jangutter has quit IRC16:31
*** armstrongs has joined #zuul16:38
*** mattw4 has joined #zuul16:40
armstrongsyeah at the moment we see that the tag regex works if you have 1 master branch as the tag is always on master. If you have multiple branches then it doesn't work as the git event can be against any branch and it won't match the tag regex specified. So in the current state it looks like zuul has the issue to users as the functionality works with 1 b16:41
armstrongsranch bt fails with multiple branches. So it appears to work for a period then stop working16:42
*** jpena is now known as jpena|off16:42
fungithe other gotcha is that tags aren't required to reference a commit on any branch at all16:43
fungithe assumption with that change is that corner cases like that can just be documented as undefined behaviors16:44
fungisame with the choice to just pick a branch based on some heuristic if the tag corresponds to a commit present in multiple branch histories16:44
armstrongsyeah so when we match against ref: ^refs/tags/.*$ on push it won't trigger currently unless that event is specifically on master. Could we wildcard in some way the branch so it triggers on any tag the latest master ref?16:50
armstrongsas the issue is we cant invoke an event against master on a new tag. That would be solved by having a branch agnostic trigger mechanism that just watches for tags against * (wildcard) branch and then triggers an action.16:54
clarkbif you dont specify a branch it should run the job against all tags16:57
clarkbthen the job can decideif actions need to be taken16:57
armstrongsim not seeing that behaviour16:57
*** AshBullock has quit IRC16:57
clarkbpretty surethat is how all the openstack release jobs work16:58
clarkbmaybe the job has to be listedin a branchless repo for that?16:58
fungiit may also be a behavior difference between how tag ref events are emitted by github vs gerrit?16:59
fungibut yeah, we run jobs on tags pushed for commits not present on master branches in opendev all the time16:59
armstrongshttp://paste.openstack.org/show/755082/16:59
*** igordc has joined #zuul16:59
fungiit's a primary workflow for many of our projects (stable point release tags on stable maintenance branches)17:00
armstrongsthat at the moment only triggers when you have 1 master branch. But doesnt trigger when you have multiple17:00
armstrongsso my thought was on the push event that defaults somehow to master17:01
*** hwangbo has joined #zuul17:01
armstrongsas it seems it is filtering out other branches and the events look like they are against them17:01
fungithis pipeline triggers builds for us on any tag regardless of the branch for which it was pushed: https://opendev.org/openstack/project-config/src/branch/master/zuul.d/pipelines.yaml#L217-L23417:01
armstrongsyup you guys sent that example and i used it for reference so it was working great with 1 master branch. When you create feature branches it stops working.17:03
fungii'm not sure what you mean by "multiple master branches" though (git shouldn't allow more than one branch with the same name on the same remote)17:03
armstrongsi meant multiple branches on the repo17:03
fungiahh17:03
armstrongsso master and say a new branch called test17:03
fungiyeah, i wonder if this is a problem with the github connection driver17:03
armstrongsso the event looks like the tag event comes through with test in the path and then it looks like it isn't firing.17:05
fungidoes the job definition include any sort of explicit branch matcher?17:05
armstrongsnah i tried with and without made no difference17:06
clarkbis the job listed in a branched repo?17:07
clarkbcould be the implicit matchers aren't doing what we want17:07
armstrongsso the "test" branch is branched from "master" and they have the same zuul.yaml and same jobs if thats what you mean. However, the branch is just using a PR event with associated jobs. While master is triggering on a push.17:09
armstrongsbased on tag regex i pasted above17:10
clarkbya maybe move the job and its pipeline config into a config repo that doesn't have branches and see if that changes the behavior?17:11
clarkball of the openstack release jobs are in a config repo with only a master branch17:11
clarkb(maybe for this reason?)17:11
*** armstrongs has quit IRC17:12
*** armstrongs has joined #zuul17:12
armstrongsyeah it works with 1 branch but i need the repo to be able to support a master build based on a tag pushed to repo and also support PR jobs too17:13
armstrongswhich is our current issue17:14
clarkbright if the job config lives in a config repo that only has master branch then you can apply that to all the events from whichever branch or tag on the other repo?17:14
armstrongsthe config job has only 1 branch. I meant the untrusted project has 2 pipelines 1 for push based on tag regex and another for PR events against a branch. That untrusted project has a number of branches not just 1. The push pipeline with tag regex works when we have 1 branch on the untrusted project. When you go to 2 branches the push event doesnt f17:22
armstrongsire.17:22
fungiyeah, so this is sounding more and more like it could be a behavior difference between gerrit ref-updated events and github push events17:23
armstrongsindeed17:23
fungibecause you've basically described precisely what we're doing in opendev with gerrit and it's been working there17:23
*** jamesmcarthur_ has quit IRC17:24
AJaegerarmstrongs: see https://docs.openstack.org/infra/manual/creators.html#central-config-exceptions - we leave the tag job configuration on purpose in a central branchless17:26
AJaegerrepository17:27
armstrongssorry i may be being slow so you are saying my push jobs should be defined in the zuul.d/projects.yaml in the config repository and dont put them on the .zuul.yaml on my untrusted project and that will make the difference?17:41
*** armstrongs has quit IRC17:47
fungiunfortunately https://review.openstack.org/571520 which introduced that guidance didn't come with any accompanying rationale to indicate whether tag jobs should have their pipline additions in a config repo for workflow/policy reasons or because of how zuul interprets them17:52
fungiclarkb: you were the author of that ^ change, perhaps you remember?17:52
*** armstrongs has joined #zuul17:54
fungii know we have plenty of projects in opendev adding jobs to tag-based pipelines within their own untrusted repos, but i don't know whether any of them tag on more than just a master branch17:54
clarkbfungi: it needs to be a branchless repo iirc17:56
clarkband our branchless repo happens to be a config repo too17:56
*** armstrongs has quit IRC17:59
*** electrofelix has quit IRC18:06
*** jamesmcarthur has joined #zuul18:12
*** jamesmcarthur has quit IRC18:52
*** jamesmcarthur has joined #zuul19:04
openstackgerritJeff Liu proposed zuul/zuul-jobs master: Add auth config to kubelet user for buildset registries  https://review.opendev.org/67335119:07
*** jamesmcarthur has quit IRC19:54
*** jamesmcarthur has joined #zuul19:58
*** jamesmcarthur has quit IRC20:03
openstackgerritJeff Liu proposed zuul/zuul-jobs master: Add auth config to kubelet user for buildset registries  https://review.opendev.org/67335120:06
corvusmordred: the whole js log series is green if you want to review the last 4 changes (673105 is the tail)20:17
openstackgerritSorin Sbarnea proposed zuul/zuul-jobs master: WIP: Allow ensure-tox to upgrade tox version  https://review.opendev.org/67276020:17
openstackgerritJeff Liu proposed zuul/zuul-operator master: use opendev image building system for zuul-operator test  https://review.opendev.org/67302020:23
*** jamesmcarthur has joined #zuul20:25
*** jamesmcarthur has quit IRC20:31
*** armstrongs has joined #zuul20:37
mordredcorvus: woot!20:41
*** armstrongs has quit IRC20:43
*** jamesmcarthur has joined #zuul20:59
clarkbcorvus: at the base of that js stack you've got some js that returns action types to reducers. That all seems fine except you've also got jsx that seems to do overlapping work for rendering log dir trees. I'm mostly lost in what the tie in between the two sides is (and why they aren't redundant)21:01
clarkbparticularly for the manifest stuff21:01
clarkbI think for the logfile stuff that is largely js21:01
corvusthey are *slightly* redundant --21:02
corvusbasically the action -> reducer part takes the json data structure from zuul and converts it into 2 data structures -- one is a hash of filename -> node info (so that when we hit a render url, we can look up the mimetype quickly).  the other produces a tree that is very similar to what we get from zuul, but it uses 'nodes' instead of 'children', because that's what the TreeView wants.21:03
*** jamesmcarthur has quit IRC21:03
corvusclarkb: on the jsx side, we walk the 'nodes' tree and replace the 'text' attribute with some jsx objects so that it's more than just a string, it's a link (and in a later change, several links and an icon)21:04
corvusthe reason i don't just do that in the actions file is that it isn't a jsx file21:04
corvus(and i don't think i should turn it into one)21:04
corvusso basically, i do as much conversion to the forms we're going to use later as early as possible, but then there's that last bit of adding in some html entities at the end.21:05
corvushonestly, if TreeView were a better implementation, i wouldn't be putting the UI elements into that data structure.  but it is what it is.  so given that, at least that only happens right there with the rest of the ui generation code.21:06
clarkbout of curioustiy why not do the conversions entirely in jsx?21:08
fungiif anybody has time to review 673353 (dns) and 673355 (system-config) changes, i can load data onto the last replacement gitea servers this afternoon21:09
corvusi wanted the index generation done only once, ahead of time, so that lookups of direct file urls are fast.  had to walk the tree for that anyway, may as well do any other structural changes there.21:09
corvus(and i think i'm subconciously hoping that we replace treeview with something that doesn't need the weird jsx thing at the end)21:10
fungid'oh, sorry, wrong channel21:11
corvushowever, setting that aside, we could move some of the stuff in actions to the view; but we'd still be walking the tree both places, so it's sort of six-of-one.21:11
openstackgerritJeff Liu proposed zuul/zuul-jobs master: Add auth config to kubelet user for buildset registries  https://review.opendev.org/67335121:13
clarkbcorvus: couple of notes on https://review.opendev.org/#/c/672839/321:31
corvusclarkb: replied21:33
corvus(the lack of named groups made me grumpy, but i got over it.  in later versions of JS, that feature is there, but i didn't want to work out whether we could rely on it yet)21:34
clarkboh ya that is too bad21:35
*** jeliu_ has quit IRC21:37
mordredcorvus: yes, I believe we can - it's in es2018 which also is where ... syntax is found, which we are using21:38
corvusoh neat; then next time we're in there, we should see about using that21:39
mordredyeah21:39
*** jamesmcarthur has joined #zuul21:39
corvus(we apparently do not have our linter configured for that, because it barfed at me when i tried to use it)21:39
*** jamesmcarthur has quit IRC21:40
*** jamesmcarthur_ has joined #zuul21:40
mordredcorvus: hrm. actually - I might be wrong21:41
mordredlooks like react-scripts currently supports object/rest spread syntax (...) from es2018 - and one or two other things, but so far doesn't support named capture groups21:42
mordredcorvus: the stack is +A'd except for https://review.opendev.org/#/c/671906 - which clarkb +1'd but said you can treat as a +2 if you want21:53
mordredcorvus: I agree - I would be happy for you to +A that21:53
clarkbya I basically noted that I'm still not super strong on all the stuff changing there21:53
clarkbbut what I do understand seems fine21:53
*** tosky has quit IRC22:32
*** michael-beaver has quit IRC22:32
*** mattw4 has quit IRC22:35
*** mattw4 has joined #zuul22:35
*** saneax has joined #zuul22:57
*** tjgresha has joined #zuul23:08
corvusi went ahead and +W'd that.  might take a bit to get the whole stack in23:23
*** mattw4 has quit IRC23:56

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!