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