chef - Conductores alternos con cocina de prueba.

test-kitchen

Question

Muchos libros de cocina, como el libro de cocina mysql, tienen varios archivos .kitchen.yml. Por ejemplo, mysql tiene un .kitchen.yml y un .kitchen-cloud.yml. En cuanto a la documentación y el código de prueba de cocina, no veo ninguna forma de usar archivos de configuración que no sean .kitchen.yml , .kitchen.local.yml y ~/.kitchen/config.yml . Si quisiera usar el controlador en la nube del libro de cocina mysql , yo:

• cp .kitchen-cloud.yml .kitchen.yml
• cp .kitchen-cloud.yml .kitchen.local.yml
• ¿¿algo más??

Parece que debería haber un enfoque más limpio para usar el archivo de configuración alternativo que un reemplazo de fuerza bruta de los predeterminados.

Gracias

Answer 1

... para agregar a coderanger, si desea seleccionar controladores u opciones en función de si su herramienta de CI establece variables de entorno, también podría hacer algo como esto:

---
<%
  #--------------------------------------------------------------------------
  # the driver_plugin can be overridden with an environment variable:
  #   $ KITCHEN_DRIVER=docker kitchen test
  # if not specified, defaults are used...
  #   - kitchen_driver_ci if environment variable CI=true or TRAVIS=true are present
  #   - kitchen_driver_local is used otherwise (which defaults to vagrant)
  #--------------------------------------------------------------------------

  kitchen_driver_ci = ''ec2''
  kitchen_driver_local = ''vagrant''
  kitchen_driver_default = kitchen_driver_local

  if ENV[''KITCHEN_DRIVER'']
    kitchen_driver = ENV[''KITCHEN_DRIVER'']
  elsif ENV[''TRAVIS'']=="true"
    kitchen_driver = kitchen_driver_ci
  elsif ENV[''CI'']=="true"
    kitchen_driver = kitchen_driver_ci
  else
    kitchen_driver = kitchen_driver_default
  end
  puts "-----> driver_plugin: #{kitchen_driver.to_s}"    
%>

driver_plugin: <%= kitchen_driver %>
driver_config:
  require_chef_omnibus: 11.10.4
  <% if kitchen_driver == ''ec2'' %>
  aws_access_key_id:      <%= ENV[''AWS_ACCESS_KEY_ID''] %>
  aws_secret_access_key:  <%= ENV[''AWS_SECRET_ACCESS_KEY''] %>
  aws_ssh_key_id:         <%= ENV[''AWS_SSH_KEY_ID'']         || "test-kitchen" %>
  ssh_key:                <%= ENV[''AWS_SSH_KEY_FILE'']       || "./test-kitchen.pem" %>
  region:                 <%= ENV[''AWS_REGION'']             || "us-east-1" %>
  availability_zone:      <%= ENV[''AWS_AVAILABILITY_ZONE'']  || "us-east-1c" %>
  flavor_id: "t2.small"
  groups: ["test-kitchen"]
  <% end %>
  <% if kitchen_driver == ''vagrant'' %>
  customize:
    memory: 2048
  <% end %>

platforms:
- name: ubuntu-14.04
  <% if kitchen_driver == ''ec2'' %>
  driver_config:
    image_id: ami-6ab2a702
    username: ubuntu
    tags: { "Name": "Test Kitchen" }
  <% end %>

busser:
  sudo: true

suites:
- name: default
  run_list: [
  ]
  attributes: {
  }

De esta manera usted mantiene un solo archivo y evita las pruebas de plataforma divergentes (hacer un cambio en un archivo y olvidarse en otro). También hay casos en los que las opciones proporcionadas en .kitchen.local.yml pueden entrar en conflicto con las de .kitchen.yml.

Answer 2

Además de lo que dijo zts, recuerde que puede usar ERb en ​​archivos de cocina, por lo que la configuración de su controlador puede verse así:

driver:
  name: <%= ENV[''KITCHEN_DRIVER''] || ''vagrant'' %>

Answer 3

Encontré esta pregunta mientras buscaba una solución para admitir varios controladores con un archivo de cocina y la respuesta de Ives fue muy útil. Lo adapté para hacer lo siguiente.

• Predeterminado para el controlador vagrant
• Permitir que el usuario anule la configuración del controlador con una variable de entorno KITCHEN_DRIVER
• Seleccione el controlador docker_ssh si está instalado.

---
<%
require ''rubygems''
kitchen_driver = ''vagrant''

if ENV[''KITCHEN_DRIVER'']
    kitchen_driver = ENV[''KITCHEN_DRIVER'']
elsif Gem::Specification::find_all_by_name(''kitchen-docker_ssh'').any?
    kitchen_driver = ''docker_ssh''
end
%>

driver:
  name: <%= kitchen_driver %>

Answer 4

Kitchen proporciona tres variables de entorno para controlar dónde busca cada uno de los archivos de configuración posibles. Para hacer explícito el comportamiento predeterminado, puede establecerlos de la siguiente manera:

KITCHEN_YAML="./.kitchen.yml"
KITCHEN_LOCAL_YAML="./.kitchen.local.yml"
KITCHEN_GLOBAL_YAML="$HOME/.kitchen/config.yml"

No es necesario que los anule todos, por lo que podría ejecutar la prueba de cocina con su .kitchen-cloud.yml así:

$ KITCHEN_YAML=".kitchen-cloud.yml" kitchen test