Integration tests with DigitalOcean (see #180)

[mcgege]

Signed-off-by: Michael Geiger info@mgeiger.de

[artem-sidorenko]

There is a way to avoid duplications of this with vagrant and DO setup, kitchen.yml is processed by ERB before it gets evaluated as yaml, so following tricks are possible with it (example from my private chef monorepo):

# some top-level kitchen.yml which is included by monorepo cookbooks
---
<% if (ENV['DIGITALOCEAN_ACCESS_TOKEN'] && ENV['DIGITALOCEAN_SSH_KEY_IDS'] && ENV['SSH_KEY_PATH']) || ENV['CI'] %>
driver:
  name: digitalocean
  size: s-1vcpu-1gb
  region: fra1
  ipv6: true

transport:
  ssh_key: <%= Monorepo.path(ENV['SSH_KEY_PATH']) %>
  max_wait_until_ready: 30
<% else %>
driver:
  name: vagrant
<% end %>

<% if (ENV['DIGITALOCEAN_ACCESS_TOKEN'] && ENV['DIGITALOCEAN_SSH_KEY_IDS'] && ENV['SSH_KEY_PATH']) || ENV['CI'] || $KITCHEN_FORCE_CI_PLATFORMS %>
platforms:
- name: ubuntu-16.04
  driver_config:
    image: ubuntu-16-04-x64
- name: centos-7
  driver_config:
    image: centos-7-x64
- name: debian-9
  driver_config:
    image: debian-9-x64
<% else %>
platforms:
  - name: ubuntu-16.04
    driver_config:
      box: bento/ubuntu-16.04
      gui: false
  - name: centos-7
    driver_config:
      box: bento/centos-7.5
  - name: debian-9
    driver_config:
      box: bento/debian-9.6
  - name: mint-18-cinnamon
    driver_config:
      box: artem-sidorenko/mint-18.3-cinnamon
      gui: false
      customize:
        memory: 1024
        vram: 32
<% end %>

provisioner: &global-provisioner
  name: chef_zero
  data_bags_path: <%= Monorepo.path('test/fixtures/data_bags') %>
  roles_path: <%= Monorepo.path('roles') %>
  attributes:
    kitchen-test-run: true
    kitchen-fast-test: <%= (ENV['CI_COMMIT_REF_SLUG'] == 'master' && (ENV['CI_PIPELINE_ID'].to_i % 3).zero?) ? 'false':'true' %>
  log_level: 'warn'
  product_name: 'chef'
  product_version: '14.12.3'
  #deprecations_as_errors: true

verifier:
  name: inspec
  attributes:
    kitchen-fast-test: <%= (ENV['CI_COMMIT_REF_SLUG'] == 'master' && (ENV['CI_PIPELINE_ID'].to_i % 3).zero?) ? 'false':'true' %>
<% if File.exist?('test/integration/attributes.yml') %>
  attrs:
    - test/integration/attributes.yml
<% end %>

# some cookbook specific yaml
<% require_relative '../../../lib/monorepo' %>
<%= Monorepo::Kitchen.global_config %>

provisioner:
  <<: *global-provisioner
  data_bags_path: 'test/fixtures/data_bags'
  environments_path: test/fixtures/environments
  client_rb:
    environment: default

.default-suite: &default-suite
  run_list:
    - recipe[openvpn-client-test]
    - recipe[openvpn-client]
  includes:
    - ubuntu-16.04
    - mint-18-cinnamon
    - centos-7

suites:
- name: default
  <<: *default-suite
- name: two-profiles
  <<: *default-suite
  provisioner:
    client_rb:
      environment: two-profiles

just to give an idea how cool this might get :-)

[artem-sidorenko]

but maybe it makes sense to try this out in a dedicated PR if you like

[mcgege]

Wohoho ... cool way, but I also think this should be done in a separate PR

[artem-sidorenko]

@mcgege LGTM! Should all this not be activated in the travis.yml?

[mcgege]

@artem-sidorenko I see the DO tests as an optional (and non-free) way, that can be activated on demand. From my point of view the docker tests are sufficient (and free) ;-)

[artem-sidorenko]

@mcgege you mean without costs? :-) Feel free to use (or ask me) for DO token I have for dev-sec.

For chef-os-hardening I wanted to have the full validation at least once (e.g. on master branch), just to have testing of sysctl and similar things. It's implemented like this:

• docker tests are always running (on the base branches and on the PRs)
• DO tests are running only for non-fork-branches (e.g. base master and other branches pushed by us)

Via this approach there is a full validation at least on master branch always and I optionally I can repush some PR branch to see the full validation results for PRs. I use the repushing mechanism not really often, but validation of master branch in real VMs provides me more safety