Driver alternativi con cucina di prova

Question

Molti libri di cucina, come lo mysql cookbook hanno più file .kitchen.yml. Ad esempio, mysql ha un .kitchen.yml e un .kitchen-cloud.yml. Guardando la documentazione e il codice per test-kitchen, non riesco a vedere alcun modo per utilizzare i file di configurazione diversi da .kitchen.yml, .kitchen.local.yml e ~/.kitchen/config.yml. Se ho voluto utilizzare il driver nube dal mysql libro di cucina, dovrei:

• cp .kitchen-cloud.yml .kitchen.yml
• cp .kitchen-cloud.yml .kitchen.local.yml
• qualcos'altro ??

Sembra proprio che ci dovrebbe essere un approccio più pulito all'utilizzo del file di configurazione alternativo che sostituisce la forza bruta di quelli di default.

Grazie

Answer 1

cucina offre tre variabili d'ambiente per controllare dove appare per ciascuno dei possibili file di configurazione. Per rendere il comportamento predefinito esplicito, è possibile impostare nel modo seguente:

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

Non è necessario sovrascrivere tutti loro, così da poter eseguire test-cucina con il tuo .kitchen-cloud.yml in questo modo:

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

Answer 2

in aggiunta a quanto detto ZTS, ricordate che potete utilizzare ERb in file da cucina, in modo che il config conducente può assomigliare a questo:

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

Answer 3

... per aggiungere al coderanger, se si desidera selezionare i driver o opzioni a seconda che il vostro strumento CI imposta le variabili d'ambiente, si potrebbe anche fare qualcosa di simile:

---

--- 
<% 
    #-------------------------------------------------------------------------- 
    # 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: { 
    } 

---

In questo modo si mantiene un singolo file e di evitare divergenti test piattaforma (fare un cambiamento in uno archiviare e dimenticare in un altro). Ci sono anche casi in cui le opzioni fornite in .kitchen.local.yml potrebbero entrare in conflitto con quelle di .kitchen.yml.

Answer 4

Ho trovato questa domanda mentre cercavo una soluzione per supportare più driver con un file di cucina e la risposta di Ives è stata molto utile. L'ho adattato per fare quanto segue.

• predefinito per il driver vagabondo
• Consenti all'utente di ignorare l'impostazione del driver con un ambiente KITCHEN_DRIVER variabile
• Selezionare il driver docker_ssh se è installato.

--- 
<% 
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 %>