Open dkingofpa opened 12 years ago
I can look into adding an option for that. I'm unsure about whether to make it on by default though.
If you are deploying a drupal site, what do you need to deploy besides the code defined in the make file? Any custom modules, themes, etc. should probably be included in the make file. If it isn't, then the user will need to make other arrangements (probably special cases) to deploy those parts of the project.
For example, if we don't include the custom theme in distro.make, we need to manually deploy that ourselves (usually via git clone).
How are your example/test drupal projects structured? Are there any other files at the same level as the make file?
This seems reasonable to me. I think I'll introduce an option for this in 1.1 and then make the option default in 2.0.
On Mon 02 Jul 2012 08:33:51 PM EDT, David King wrote:
If you are deploying a drupal site, what do you need to deploy besides the code defined in the make file? Any custom modules, themes, etc. should probably be included in the make file. If it isn't, then the user will need to make other arrangements (probably special cases) to deploy those parts of the project.
For example, if we don't include the custom theme in distro.make, we need to manually deploy that ourselves (usually via git clone).
How are your example/test drupal projects structured? Are there any other files at the same level as the make file?
Reply to this email directly or view it on GitHub: https://github.com/xforty/drush-deploy/issues/2#issuecomment-6723430
The best workaround I've found is to make sure distro.make is in it's own folder. Then any extraneous files can be cleaned up via a task in a Capfile.
require 'drush_deploy'
before "deploy:symlink", "project:cleanup"
namespace :project do
desc "Cleans up extraneous files uploaded by drush-deploy along with the actual code for the site."
task :cleanup do
run "cd #{latest_release} && rm Capfile distro.make"
end
end
Working on wrapping the source method from the Copy deploy strategy.
Working on overriding export, checkout and sync
For checkout we could add a hidden symlink back to the real checkout. On sync, rm the make'd drupal dir, sync the real checkout, and then re-run the make
So discussing 472f376 with @medlefsen it is clearer to me what is being asked. Our checkout, export and sync methods for the source object need to work for SCM::None or any other SCM type configured. The way to handle simply call the checkout, export or sync method. We only need to concern ourselves with a different end result for the files in the destination if make_clean is true. The way to handle that is to use temp directory for checkout or export (sync is a special case, which effect checkout) then run drush make into the destination after the source object method call to checkout, export or sync has been made. This is functionality worth pursuing so it works more completely with standard Capistrano configurations
In a vagrant-drupal project, all the vagrant environment files and folders are at the same level as distro.make. If I run drush-deploy on those projects, all the vagrant-drupal files and folders are deployed to the docroot of the site. I expect only the code defined in distro.make to be deployed.