67 votes

Déployer un sous-répertoire Git dans Capistrano

Mon agencement de la branche principale est le suivant :

/ <-- niveau supérieur

/client <-- fichiers sources du client de bureau

/serveur <-- Application Rails

Ce que j'aimerais faire, c'est de ne récupérer que le répertoire /server dans mon deploy.rb mais je n'arrive pas à trouver le moyen de le faire. Le répertoire /client est énorme, donc la mise en place d'un hook pour copier /server vers / ne fonctionnera pas très bien, il doit seulement tirer vers le bas l'application Rails.

79voto

billitch Points 1091

Sans aucune bifurcation sale mais encore plus sale !

Dans mon config/deploy.rb :

set :deploy_subdir, "project/subdir"

J'ai ensuite ajouté cette nouvelle stratégie à mon Capfile :

require 'capistrano/recipes/deploy/strategy/remote_cache'

class RemoteCacheSubdir < Capistrano::Deploy::Strategy::RemoteCache

  private

  def repository_cache_subdir
    if configuration[:deploy_subdir] then
      File.join(repository_cache, configuration[:deploy_subdir])
    else
      repository_cache
    end
  end

  def copy_repository_cache
    logger.trace "copying the cached version to #{configuration[:release_path]}"
    if copy_exclude.empty? 
      run "cp -RPp #{repository_cache_subdir} #{configuration[:release_path]} && #{mark}"
    else
      exclusions = copy_exclude.map { |e| "--exclude=\"#{e}\"" }.join(' ')
      run "rsync -lrpt #{exclusions} #{repository_cache_subdir}/* #{configuration[:release_path]} && #{mark}"
    end
  end

end

set :strategy, RemoteCacheSubdir.new(self)

14 votes

Oh, comme j'aimerais pouvoir vous envoyer quelques pintes de bière fraîche. Merci !

3 votes

Parfait. Juste ce dont j'avais besoin. Merci !

0 votes

NB : pour ceux qui lisent, cela fonctionne si vous utilisez déjà remote_cache comme mécanisme :deploy_via (qui repose sur l'accès SCM du côté serveur).

44voto

Mr Friendly Points 101

Pour Capistrano 3.0, j'utilise ce qui suit :

Dans mon Capfile :

# Define a new SCM strategy, so we can deploy only a subdirectory of our repo.
module RemoteCacheWithProjectRootStrategy
  def test
    test! " [ -f #{repo_path}/HEAD ] "
  end

  def check
    test! :git, :'ls-remote', repo_url
  end

  def clone
    git :clone, '--mirror', repo_url, repo_path
  end

  def update
    git :remote, :update
  end

  def release
    git :archive, fetch(:branch), fetch(:project_root), '| tar -x -C', release_path, "--strip=#{fetch(:project_root).count('/')+1}"
  end
end

Et dans mon deploy.rb :

# Set up a strategy to deploy only a project directory (not the whole repo)
set :git_strategy, RemoteCacheWithProjectRootStrategy
set :project_root, 'relative/path/from/your/repo'

Tout le code important est dans la stratégie release qui utilise la méthode git archive pour archiver uniquement un sous-répertoire du repo, puis utilise la fonction --strip argument pour tar pour extraire l'archive au bon niveau.

UPDATE

À partir de Capistrano 3.3.3, vous pouvez désormais utiliser la fonction :repo_tree ce qui rend cette réponse obsolète. Par exemple :

set :repo_url, 'https://example.com/your_repo.git'
set :repo_tree, 'relative/path/from/your/repo' # relative path to project root in repo

Voir http://capistranorb.com/documentation/getting-started/configuration .

0 votes

Je n'ai pas pu définir la stratégie personnalisée à l'aide de la commande "set :git_strategy", car la stratégie par défaut est toujours utilisée.

7 votes

J'ai également dû copier et coller la méthode "fetch_revision" de l'original.( github.com/capistrano/capistrano/blob/master/lib/capistrano/ )

1 votes

@TsuneoYoshioka Oui, la méthode "fetch_revision" a été ajoutée dans Capistrano 3.1. Cependant, la 3.1 a également ajouté la variable de configuration 'repo_tree', ce qui rend (heureusement) cette réponse obsolète. Voir github.com/capistrano/capistrano#configuration pour les détails.

10voto

Thomas Fankhauser Points 1899

Nous faisons également cela avec Capistrano en clonant le dépôt complet, en supprimant les fichiers et dossiers inutilisés et en déplaçant le dossier désiré vers le haut de la hiérarchie.

deployer.rb

set :repository,  "git@github.com:name/project.git"
set :branch, "master"
set :subdir, "server"

after "deploy:update_code", "deploy:checkout_subdir"

namespace :deploy do

    desc "Checkout subdirectory and delete all the other stuff"
    task :checkout_subdir do
        run "mv #{current_release}/#{subdir}/ /tmp && rm -rf #{current_release}/* && mv /tmp/#{subdir}/* #{current_release}"
    end

end

Tant que le projet ne devient pas trop gros, cela fonctionne assez bien pour nous, mais si vous le pouvez, créez un dépôt propre pour chaque composant et regroupez-les avec des submodules git.

1 votes

Joli ! Un peu inefficace, mais pas un hack moche au moins.

0 votes

Et n'oubliez pas d'établir manuellement un lien symbolique avec le répertoire du journal, car capistrano ne le fait plus automatiquement

2 votes

Pour une approche plus efficace. Il y a une gemme que quelqu'un a créé qui ajoute une stratégie de déploiement "copy_subdir". Seul le sous-répertoire du repo est archivé et copié sur le serveur distant. github.com/yyuu/capistrano-copy-subdir

3voto

Federico Builes Points 1940

Vous pouvez avoir deux dépôts git (client et serveur) et les ajouter à un "super-projet" (app). Dans ce "super-projet", vous pouvez ajouter les deux dépôts en tant que submodules (vérifier ce tutoriel ).

Une autre solution possible (un peu plus sale) est d'avoir des branches séparées pour le client et le serveur, et ensuite vous pouvez tirer de la branche 'serveur'.

1voto

Silas Points 990

Malheureusement, git ne fournit aucun moyen de le faire. Au lieu de cela, la "méthode git" consiste à avoir deux dépôts - client et serveur - et à cloner celui ou ceux dont vous avez besoin.

0 votes

Mentionner la "méthode Git" n'aide rien ni personne.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X