Closed bbaugher closed 7 years ago
We're seeing this in chef/chef tests @someara. We've pinned chef/chef and dk back to 1.1 for now to get around it. Here's a failure in Travis: https://travis-ci.org/chef/chef/jobs/199125788
I've added tests to make sure that the code paths that connect over a tcp socket get exercised.
I was expecting (hoping?) to reproduce this there, but no such luck.
Any more clues?
-s
seeing this as well.
can you post your .kitchen.dokken.yml?
and are you using a local or remote docker host
https://gist.github.com/majormoses/cf303fef69f75fd25f7bc6e245c6a38e local docker host running in jenkins.
looks fine... kitchen log?
@someara I will have to get that to you Monday
Same issue here:https://travis-ci.org/dhoer/chef-flywaydb/builds/203057052
running into this as well with the rundeck cookbook in a pull request https://github.com/Webtrends/rundeck/pull/133 (specifically at commit https://github.com/atheiman/rundeck/tree/32462a2f5e6f89914e8cb0446231ad4dcabf5685)
you can see full debug kitchen output in travis here https://travis-ci.org/Webtrends/rundeck/jobs/203660470#L6945
Tests are passing with kitchen-vagrant
I've pinned back to kitchen-dokken 1.1.0 for now to get past this
Aha. was able to hit this by cloning the rundeck repo..
converge works.... it seems to blow up in verify. I noticed you're using serverspec rather than Inspec....
@bbaugher @tas50 @majormoses @dhoer are you all using serverspec as well?
-s
Yes I am using serverspec
Manually tested this fix 749e3a104cefee6f0db1896ae11191edc7d05c1e against rundeck. Hopefully it should fix everyone up.
Released as 2.1.0 to make pinning easier
-s
spoke too soon... that's busted.... investigating
@someara yes, using serverspec
okay... lets give kitchen-dokken-2.1.1 a whirl
It works! https://travis-ci.org/dhoer/chef-flywaydb 👍
Thanks for taking a look at this.
Yes this fixed it for me
this seems to have fixed the issue for me as well. thanks!
@tas50 you should be good to go as well. closing this.
@someara FYI, I don't know if this fix is causing this, but windows build is super slow and fails on unit tests because it stalls out. Unit tests run for over 30 minutes, before stalling out.
https://ci.appveyor.com/project/dhoer/chef-flywaydb/build/master-77
But pinning dokken to 1.1.0, the build is faster and no stalling.
https://ci.appveyor.com/project/dhoer/chef-flywaydb/build/master-83
Does anything pop into your head as to why this would be?
There's nothing that should be making it slower.... if anything it should be faster since it's using binding mounting instead of SCP'ing files into the data container.
Perhaps it's a transient thing? That kinda thing happens on Travis all the time due to noisy neighbors on the VM hosts.
I tested it, and it seems having dokken v2.1.1 gem will cause the build to fail on windows. It doesn't make sense to me why that would be. The code change doesn't look like it would cause this. Note that windows is 32 bit, could that be the reason?
Perhaps theres a bug with Docker on Windows? It's bind mounting 3 things... chef, kitchen, and verifier directories.
Not seeing anything in the appveyor logs, and I don't have access to a windows machine -s
I'm not using docker on windows, it is just pulling in the kitchen-dokken. Not sure if it is kitchen-dokken or one of its dependencies causing the builds to stall. But the behavior is repeatable and consistent when switching from 1.1.0 to 2.1.1. I could maybe add a linux gem group, but I rather not, because it would mean updating 50+ chef cookbooks.
Its only deps are docker-api and test-kitchen. I just pushed 2.1.2, which raises the test-kitchen dep to ~> 1.15.
Try that one out?
I will try to look at it this weekend.
Here is my kitchen log. Seems like it might be failing here?
I managed to switch back to 1.1.0 to get around this