Run test-kitchen suites in cloud hosting via Travis #108
Conversation
|
Hm. Maybe kitchen-digitalocean would be better. From our end, seems cheaper, and then we don't need to manage 2 AWS accounts in order to keep things clean and separate from our other running instances... Thoughts @mrjcleaver? |
|
How much would the code need to change to use kitchen-digitalocean instead of aws (is it just 1 line in a config file?) Digital Ocean does charge to keep a switched-off image, can you confirm we'd be destroying? |
|
This seems to indicate positively on the hourly billing: And this is all the AWS-specific stuff needed: https://github.com/mission-impossible-android/chef-cm-update-server/blob/master/.kitchen.travis.yml Would be less for DigitalOcean, as there's no complexity in availability zones or ami ids |
patcon
changed the title
When an attr is nil, it doesn't have this method and fails. This no longer detects empty strings, but that's probably not something to rely on anyhow.
| @@ -3,10 +3,10 @@ | |||
| # Local modifications will be overwritten by Chef. | |||
| # | |||
| <VirtualHost *:<%= node['stash']['apache2']['port'] %>> | |||
| <% unless node['stash']['apache2']['virtual_host_name'].empty? -%> | |||
There was a problem hiding this comment.
For some reason, DigitalOcean images don't have an FQDN (from which this is set in attributes), so it's nil and there's not #empty?. Realized we probably shouldn't be using this method anyhow, so swapped it out.
If we really want something robust (I'm not sure it's an edgecase worth pandering to) then we could perhaps use #blank? from chef-sugar cookbook:
https://github.com/sethvargo/chef-sugar#core-extensions
I don't think that's worth it though -- a blank string shouldn't be set for any of these anyhow.
There was a problem hiding this comment.
Hm. Seems we are using blank strings for some of this stuff in attributes/default.rb... what are your thoughts here @linc01n? Using nil for unset things seems more sensible to me. Or we could mix-and-match approaches in this template, and just assume nil is the blank value for the virtual_host_* attrs.
There was a problem hiding this comment.
And just confirmed that chef-sugar would resolve this. That cookbook is pretty established and has lots of other things that wemight benefit from using, so perhaps we could add it?
There was a problem hiding this comment.
Adding chef-sugar is ok i think.
|
Anyhow, added chef-sugar. Lemme know if that's not OK :) |
|
Hm. I'll still test on my repo, but we'll probbaly want to add convert the travis scripts into files in |
patcon
force-pushed
the
feature/108-test-kitchen-cloud
branch
from
a75b699 to
279c221
Compare
* postgresql::ruby requires build-essential to run at compile time, and so it also needs apt repos updated.
Long logs (4MB+) make Travis thing that it's in a loop, and it will cancel the build job. We seem to hit this with the verbosity of chef 12.
Travis CI will cancel jobs when the logs get over 4MB, so this helps avoid that.
https://github.com/mission-impossible-android/chef-cm-update-server/blob/master/.travis.yml
I would basically set it up like I've done here, and then we could get tests running on master all the time for all platforms, and not worry about ever running locally just to know if things broke
And my client, @mrjcleaver of Blended Perspectives, has agreed to sponsor the AWS time (within reason) that we'll need to keep this going. Woo! Thanks @mrjcleaver!