| jlk | SpamapS: started using a box with 8 CPUs | 01:32 |
|---|---|---|
| *** dkranz has quit IRC | 03:38 | |
| *** jamielennox is now known as jamielennox|away | 04:01 | |
| *** jamielennox|away is now known as jamielennox | 04:29 | |
| SpamapS | jlk: oh that's interesting. I wonder if we need to have like --concurrency=(($ncpu - 1)) to allow for system stuff | 05:32 |
| *** jamielennox is now known as jamielennox|away | 06:52 | |
| *** jamielennox|away is now known as jamielennox | 11:18 | |
| *** jamielennox is now known as jamielennox|away | 12:05 | |
| *** _ari_ is now known as ari|gone | 12:38 | |
| *** ari|gone is now known as _ari_|gone | 12:38 | |
| *** hashar has joined #zuul | 12:56 | |
| mordred | so - re: the scrollback - jlk maybe try disabling the mysql tests real quick and see if things work consistently - jesusaur is right, that was a recent add and we haven't _generally_ been having test suite flakiness issues | 13:55 |
| mordred | before we test run bisect it might be an easyish hypothesis to test to narrow things down | 13:56 |
| *** dkranz has joined #zuul | 14:22 | |
| hashar | hello! Just in case, voluptuous got some new 0.10.x releases yesterday ( https://pypi.org/project/voluptuous/#history ) | 15:03 |
| hashar | and that seems to break Zuul 2.5 layout validation | 15:03 |
| *** jasondotstar_ has joined #zuul | 15:10 | |
| *** mordred1 has joined #zuul | 15:10 | |
| *** jasondotstar has quit IRC | 15:10 | |
| *** adam_g has quit IRC | 15:10 | |
| *** mordred has quit IRC | 15:10 | |
| *** TheJulia has quit IRC | 15:10 | |
| *** rattboi has quit IRC | 15:10 | |
| *** EmilienM has quit IRC | 15:10 | |
| *** Shrews has quit IRC | 15:10 | |
| *** Shrews has joined #zuul | 15:11 | |
| *** adam_g has joined #zuul | 15:11 | |
| *** rattboi has joined #zuul | 15:11 | |
| *** 21WAAA2JF has joined #zuul | 15:12 | |
| pabelanger | Ya, we had the issue too | 15:16 |
| pabelanger | hashar: there is a fix in master | 15:16 |
| hashar | pabelanger: I should have looked at your repository :-] | 15:17 |
| *** TheJulia has joined #zuul | 15:18 | |
| *** mordred1 is now known as mordred | 15:46 | |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: WIP: Allow for prefixing job dir names https://review.openstack.org/456685 | 15:55 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 16:01 |
| *** hashar has quit IRC | 16:08 | |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: WIP: Allow for specifying root job directory https://review.openstack.org/456691 | 16:09 |
| *** hashar has joined #zuul | 16:21 | |
| *** openstack has joined #zuul | 16:36 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 16:39 |
| *** 21WAAA2JF is now known as EmilienM | 17:05 | |
| *** EmilienM has joined #zuul | 17:05 | |
| jlk | mordred: what's the TLDR on disabling certain tests? | 17:18 |
| *** hashar has quit IRC | 17:18 | |
| mordred | jlk: well, you can just put in a self.skipTest() into the test itself ... | 17:20 |
| mordred | SpamapS: ^^ | 17:20 |
| jlk | oh, right, could @skip it or whatever the decorator is. | 17:21 |
| SpamapS | @skipIf(os.environ.get('SKIP_THIS_TEST')) is ok if you want to be able to do it programattically at runtime without patching comments in or something. | 17:21 |
| jlk | so what I'm dealing with at the moment, some commits on my patch set fail in CI, but pass locally. and patches later in teh stack (which include the earlier patches) pass in CI | 17:21 |
| jlk | so ¯\_(ツ)_/¯ | 17:21 |
| SpamapS | do we push .testrepository from failed CI runs to the logs? | 17:22 |
| SpamapS | if not, have a test node held | 17:22 |
| SpamapS | and grab that, then you can use it to do a --analyze-isolation | 17:22 |
| SpamapS | (or just re-run with --analyze-isolation on the held node) | 17:22 |
| mordred | SpamapS: we also had the hypothesis that it might be the recently-added mysql related tests -so I was suggesting disabling them as an easy way to test that hypohthesis | 17:23 |
| mordred | SpamapS: (so if they are, we havea smaller surface are to examine) | 17:23 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 17:27 |
| jlk | oh good, running with --concurrency=4 produces a failure. | 17:46 |
| Shrews | These random failures are also appearing in the gate, yeah? b/c i cannot explain the failures in my 2 reviews that i put up this morning | 17:56 |
| * Shrews looks at jlk's review stack and sees the same thing, so assumes "yes" | 17:58 | |
| jlk | by "the gate" you mean the zuul hooked up to gerrit? | 17:58 |
| jlk | (sorry we have a "check" pipeline and "gate" pipeline, so I get confused by some terminology" | 17:59 |
| jlk | ) | 17:59 |
| Shrews | jlk: check | 17:59 |
| Shrews | gate and gerrit both start with "g", so aren't they the same person? ;) | 18:02 |
| jlk | haha | 18:04 |
| jlk | it's also confusing because Jenkins check has tests called "gate-zuul-*" | 18:05 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 18:05 |
| jlk | the jobs themselves are called "gate", but they're ran both during check and gate. | 18:05 |
| Shrews | jlk: best not think too much about it | 18:06 |
| *** dkranz has quit IRC | 18:09 | |
| jlk | LOLOL | 18:15 |
| jlk | so I disabled mysql tests, re-ran, went from 2 failures to 5. | 18:15 |
| jlk | (this is with concurrency 4, if I let it do all 8, things work) | 18:15 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: WIP: Initial code for a fingerd log streamer https://review.openstack.org/456721 | 18:23 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 18:35 |
| *** dkranz has joined #zuul | 18:53 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 19:10 |
| *** hashar has joined #zuul | 19:23 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: [WIP] Add functional test for key-name and glean https://review.openstack.org/455770 | 19:37 |
| jlk | and concurrency 7 works :/ | 19:43 |
| openstackgerrit | Paul Belanger proposed openstack-infra/nodepool master: Add functional test for key-name and glean https://review.openstack.org/455770 | 20:18 |
| pabelanger | mordred: clarkb: Shrews: ^gives us validation of keypair now | 20:18 |
| SpamapS | jlk: and no failures with --analyze-isolation? | 20:22 |
| jlk | SpamapS: trying that now, since I now have a fail state with concur 4 | 20:43 |
| jlk | Is that an option passed in like concurrency? | 20:43 |
| jlk | tox -e py27 -- --concurrency=4 --analize-isolation ? | 20:43 |
| jlk | oh I see it | 20:45 |
| clarkb | with analyze-isolation you don't set concurrency it runs single threaded in a bisecting manner iirc | 20:45 |
| clarkb | the way it works is run the setup that fails, then run --analyze-isolation after the failre and it will attempt to bisect that failure | 20:45 |
| SpamapS | Yeah it specifically looks at the order in which results were reported and tries to recreate that scenario, and then change orders, and see if that fixes things. | 20:46 |
| SpamapS | but it won't catch deadlock problems | 20:46 |
| SpamapS | which this may very well be | 20:46 |
| jlk | kk, I'm letting it run | 20:51 |
| *** hashar has quit IRC | 20:54 | |
| jlk | tests.unit.test_scheduler.TestScheduler.test_dependent_behind_dequeue unknown - no conflicts | 21:24 |
| jlk | tests.unit.test_scheduler.TestScheduler.test_two_failed_changes_at_head unknown - no conflicts | 21:24 |
| jlk | the original run had 4 failures. | 21:24 |
| jlk | hrm, I do have for lines of ERROR: in my original set, that are failures trying ot git merge things. Getting conflicts. | 21:26 |
| jlk | I thought maybe that was part of testing unmergable content | 21:26 |
| jlk | actually I think those are such tests, and a red herring. | 21:28 |
| jlk | Can somebody walk me though (2.5) how an event handles both trigger matching (of requirements perhaps) vs pipeline matching? | 21:49 |
| jlk | oh sure, now I think I see it | 21:53 |
| clarkb | I'm not sure I understand the question. Doesn't trigger matching imply pipeline matching? | 21:53 |
| jlk | sortof. The distinction I'm after is "trigger when you get this approval" vs "this approval is required for this pipline to start" | 21:54 |
| jlk | because in the latter sense, the approval may have happened from an earlier event. It's data that belongs to the change itself, rather than data in the event. | 21:55 |
| clarkb | I think in 2.5 they are the same though | 21:55 |
| jlk | they aren't exactly | 21:55 |
| clarkb | its just that the entire set of triggers is evaluated together not just those pertaining to a single event | 21:56 |
| jlk | here me out | 21:56 |
| jlk | you can, in 2.5, have a gerrit trigger config that has comment-added: and under it, approval: | 21:56 |
| jlk | which means, when a comment happens, only trigger _if_ the comment itself is adding an approval. | 21:57 |
| jlk | you can _also_ as a pipeline requirement (outside the trigger key) require specific approvals. Zuul will gather data about the change, and evaluate if it has those approvals. | 21:57 |
| clarkb | yup. The requirements are evaluated regardless of trigger iirc. So it checks all the approvals on a change even if the event is a single approval vote for example. | 21:58 |
| jlk | right | 21:58 |
| jlk | I'm fixing a bug we introduced in github | 21:59 |
| jesusaur | I think the EventFilter decides whether or not the event triggers the pipeline, and the ChangeishFilter decides if the triggered pipeline applies to a given change in the pipeline | 21:59 |
| jlk | our bug is that we weren't properly doing a filter on the specific status being set in the event | 22:01 |
| jlk | so we'd get (potentially) triggered for _any_ status. Positive, negative, some random user. | 22:01 |
| *** jamielennox|away is now known as jamielennox | 22:19 | |
| openstackgerrit | Mathieu Gagné proposed openstack-infra/zuul master: Add ability to configure Zuul web interface with zuul.config.js https://review.openstack.org/327892 | 23:28 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!