Passare i parametri a Capistrano

Question

Sto valutando la possibilità di utilizzare Capistrano come soluzione di distribuzione generica. Con "generico", intendo non-rail. Non sono contento della qualità della documentazione che sto trovando, tuttavia, concessa, non sto guardando quelli che presumono di schierare rail. Quindi cercherò semplicemente di inventare qualcosa basandomi su alcuni esempi, ma ci sono un paio di problemi che sto affrontando fin dall'inizio.

Il mio problema è che cap deploy non ha informazioni sufficienti per fare qualsiasi cosa. È importante notare che manca il tag per la versione che voglio distribuire, e questo ha da passare sulla riga di comando.

L'altro problema è come ho specificato il mio repository git. Il nostro server Git è accessibile da SSH sull'account dell'utente, ma non so come modificare deploy.rb per utilizzare l'id dell'utente come parte dell'URL scm.

Quindi, come posso realizzare queste cose?

Esempio

voglio distribuire il risultato della prima volata della seconda release. Questo è taggato nel repository git come r2s1. Inoltre, diciamo che l'utente "johndoe" ha il compito di distribuire il sistema. Per accedere al repository, deve utilizzare l'URL johndoe@gitsrv.domain:app. Quindi l'URL remoto per il repository dipende dall'id utente.

Le righe di comando per ottenere i file desiderati sarebbero questi:

git clone johndoe@gitsrv.domain:app 
cd app 
git checkout r2s1 

Answer 1

Ha Jarrad ha detto, Capistrano -ash è un buon set di base di moduli helper per implementare altri tipi di progetti, anche se non è richiesto come alla fine della giornata. È solo un linguaggio di scripting e la maggior parte delle attività vengono eseguite con i comandi di sistema e finiscono per diventare quasi come uno script di shell.

Per passare i parametri, è possibile impostare il flag -s quando si esegue il cap per fornire una coppia di valori chiave. Per prima cosa crea un'attività come questa.

desc "Parameter Testing" 
task :parameter do 
    puts "Parameter test #{branch} #{tag}" 
end 

Quindi avviare l'attività in questo modo.

cap test:parameter -s branch=master -s tag=1.0.0 

Per l'ultima parte. Consiglierei di impostare l'accesso senza password usando i tasti ssh sul tuo server. Ma se vuoi prenderlo dal corrente utente che ha effettuato l'accesso.Puoi fare qualcosa di simile.

desc "Parameter Testing" 
task :parameter do 
    system("whoami", user) 
    puts "Parameter test #{user} #{branch} #{tag}" 
end 

UPDATE: cura di lavorare con le ultime versioni di Capistrano. L'array di configurazione non è più disponibile.

Parametri globali: vedere i commenti Utilizzare set: branch, fetch (: branch, 'a-valore-predefinito') per utilizzare i parametri a livello globale. (E invece li passa con -S.)

Answer 2

Partenza capistrano-ash per una libreria che aiuta con la distribuzione non-rails. Lo uso per distribuire un'applicazione PyroCMS e funziona alla grande.

Ecco un frammento del mio Capfile per quel progetto:

# deploy from git repo 
set :repository, "git@git.mygitserver.com:mygitrepo.git" 
# tells cap to use git 
set :scm, :git 

io non sono sicuro di capire le ultime due parti della questione. Fornisci ulteriori dettagli e sarei felice di aiutarti.

EDIT dopo esempio dato:

set :repository, "#{scm_user}@gitsrv.domain:app" 

Poi ogni persona con priveledges Deploy può aggiungere quanto segue al loro locale file ~/.caprc:

set :scm_user, 'someuser' 

Answer 3

Suggerisco di utilizzare le variabili ENV.

Qualcosa come questo (comando):

$ GIT_REPO="johndoe@gitsrv.domain:app" GIT_BRANCH="r2s1" cap testing 

Cap config:

#deploy.rb: 
task :testing, :roles => :app do 
    puts ENV['GIT_REPO'] 
    puts ENV['GIT_BRANCH'] 
end 

E prendere uno sguardo al https://github.com/capistrano/capistrano/wiki/2.x-Multistage-Extension, può essere questo approccio sarà utile per voi pure.

Answer 4

Come già indicato da Jamie, è possibile passare i parametri alle attività con il flag -s. Voglio mostrarti come puoi usare anche un valore predefinito.

Se si desidera lavorare con valori di default, è necessario utilizzare fetch invece di ||= o il controllo per nil:

namespace :logs do 
    task :tail do 
    file = fetch(:file, 'production') # sets 'production' as default value 
    puts "I would use #{file}.log now" 
    end 
end 

è possibile eseguire questo compito (utilizza il valore predefinito production per file)

$ cap logs:tail 

o (utilizza il valore cron per file

$ cap logs:tail -s file=cron 

Answer 5

Aggiornamento . Per quanto riguarda i parametri di passaggio solo per l'attività Capistrano 3.

So che questa domanda è piuttosto vecchia, ma viene comunque visualizzata per prima su Google durante la ricerca dei parametri che passano all'attività Capistrano. Purtroppo, la risposta fantastica fornito da Jamie Sutherland non è più valido con Capistrano 3. Prima di sprecare il vostro tempo a cercare fuori, tranne il risultato di essere come di seguito:

cap test:parameter -s branch=master 

uscite:

cap aborted! 
OptionParser::AmbiguousOption: ambiguous option: -s 
OptionParser::InvalidOption: invalid option: s 

e

cap test:parameter -S branch=master 

uscite:

invalid option: -S 

Le risposte valide per Capistrano 3 forniti da @senz e Brad Dwyer si possono trovare cliccando questo link: oro Capistrano 3 pulling command line arguments

Per completezza vedere il codice qui sotto per scoprire due opzione che avete.

prima opzione:

È possibile scorrere le attività con la chiave e il valore come si fa con gli hash regolari:

desc "This task accepts optional parameters" 

task :task_with_params, :first_param, :second_param do |task_name, parameter| 
    run_locally do 
    puts "Task name: #{task_name}" 
    puts "First parameter: #{parameter[:first_param]}" 
    puts "Second parameter: #{parameter[:second_param]}" 
    end 
end 

Assicurarsi che non v'è alcun spazio tra i parametri quando si chiama cap:

cap production task_with_params[one,two] 

seconda opzione:

Mentre si chiama tutta l'operazione, è possibile assegnare le variabili ambientali e poi chiamare dal codice:

set :first_param, ENV['first_env'] || 'first default' 
set :second_param, ENV['second_env'] || 'second default' 

desc "This task accepts optional parameters" 
task :task_with_env_params do 
    run_locally do 
    puts "First parameter: #{fetch(:first_param)}" 
    puts "Second parameter: #{fetch(:second_param)}" 
    end 
end 

Per assegnare variabili ambientali, cap chiamata come muggito:

cap production task_with_env_params first_env=one second_env=two 

speranza che salverà tu un po 'di tempo.