Closed patcon closed 9 years ago
I comment out my .kitchen.yml
a bit. I usually test on centos only. Unless it is big release then I manually run vagrant up
one by one.
I've just run the test. It passed without problems.
# Running tests:
0.05 s = .
0.04 s = .
recipe::stash::apache2#test_0001_has apache VirtualHost = 0.00 s = .
recipe::stash::configuration#test_0001_creates Stash properties file = 0.00 s = .
recipe::stash::linux_standalone#test_0002_creates Java KeyStore = 0.00 s = .
recipe::stash::linux_standalone#test_0001_has stash user = 0.00 s = .
0.04 s = .
0.04 s = .
Finished tests in 0.186039s, 43.0017 tests/s, 43.0017 assertions/s.
8 tests, 8 assertions, 0 failures, 0 errors, 0 skips
- MiniTest::Chef::Handler
Running handlers complete
Chef Client finished, 195/283 resources updated in 697.324626043 seconds
Finished converging <default-centos-7> (12m31.15s).
Thanks! Can you confirm that you deleted your Berksfile.lock so that everything resolved as a fresh clone would?
Speaking of which, should we consider committing that? lockfiles shouldn't normally be committed, but I think that's because it would lock upstream deps too (ie with gems), but I don't think Berkshelf resolution takes lockfiles into account, so it's no loss in practice, except getting everyone on the same page during tests and general testing with vagrant :)
For example, getting this on db creation on ubuntu-1404 (I'm adding a postgresql test):
* package[autoconf] action nothing (skipped due to action :nothing)
* package[binutils-doc] action nothing (skipped due to action :nothing)
* package[bison] action nothing (skipped due to action :nothing)
* package[build-essential] action nothing (skipped due to action :nothing)
* package[flex] action nothing (skipped due to action :nothing)
* package[gettext] action nothing (skipped due to action :nothing)
* package[ncurses-dev] action nothing (skipped due to action :nothing)
Recipe: postgresql::ruby
* execute[generate pg gem Makefile] action nothing (skipped due to action :nothing)
* execute[make pg gem lib] action nothing (skipped due to action :nothing)
* execute[install pg gem lib] action nothing (skipped due to action :nothing)
* execute[install pg spec] action nothing (skipped due to action :nothing)
Recipe: stash::database
================================================================================
Error executing action `create` on resource 'postgresql_database[stash]'
================================================================================
PG::InvalidParameterValue
-------------------------
ERROR: new encoding (UTF8) is incompatible with the encoding of the template database (SQL_ASCII)
HINT: Use the same encoding as in the template database, or use template0 as template.
Cookbook Trace:
---------------
/tmp/kitchen/cache/cookbooks/database/libraries/provider_database_postgresql.rb:52:in `exec'
/tmp/kitchen/cache/cookbooks/database/libraries/provider_database_postgresql.rb:52:in `action_create'
So seems perhaps the utf8 isn't the default template in postgresql 9.3.8?
OK, so it seems that in the postgres db creation resource, the resource attributes need to be changed either so that 1) set "encoding" to DEFAULT
instead of utf8
, or 2) set template to template0
Thoughts on using kitchen-docker
by default?
I think we need to push for version 4.0 and use postgres as default. It is strange you hit this problem. My production stash is using postgres as well but it setup nicely. Maybe it is because I commited the Cheffile.lock
on my repo.
What's the benefit of using kitchen-docker
? Can it parallelize the kitchen test? I hate running kitchen test one by one so I comment out those ubuntu test case.
It can, be I didn't realize that was one of the benefits over vagrant.
Docker is more lightweight than vagrant's vbox. It can theoretically be faster than vagrant (even with vagrant-cachier), but needs a proxy like squid or polipo to see the real benefits. Also, docker works a bit less efficiently on non-debian systems like osx, as it still needs to boot a single VM to run all the containers in.
Yup. But it is good for running in CI server. Let me learn it and try to put that in.
No pressure though. My current branch allows me to use docker with a .kitchen.local.yml
with just
driver:
name: docker
So long as you're cool with a little extra in the gemfile, etc
Closing in favour of https://github.com/bflad/chef-stash/issues/107
As I'm trying to add test-kitchen support with AWS and Travis, I'm finding a few things failing locally with docker, related to the mysql cookbook and the git cookbook.
As a sanity check before I go too far down this road, have you run these tests lately? Do you expect the test-kitchen suite to work?
EDIT: Also, seems default and apache2 suites are redundant, correct?