We're using vlad the deployer to deploy our rails app.
Currently, we have some tasks that run after the vlad:update task. These tasks take a few minutes. During those few minutes, the site is broken.
I'd like to run those tasks in the middle of vlad:update -- after it has done everything except create the "current" symlink. How do I do that? the vlad:update task appears to be monolothic.
Found the answer. Define your task to run before the update_symlinks task rather than after the update task.
remote_task :finish_deployment, :roles => :app do
...
end
remote_task :update_symlinks => :finish_deployment
Related
TLDR:
I can't configure ordered chain of Puppet "Exec" commands to run ONLY ONCE.
Details:
I want to use Vagrant and Puppet modules to setup VM with installed Redmine and some sample data loaded into it.
I'm using https://forge.puppetlabs.com/johanek/redmine and it works great - Redmine is installed and it works.
My goal:
Now I want to load sample data into Redmine using REST API:
Create 1 test project
Import 2 issues into this project
I want to run 2 simple "Exec", one after another and ONLY ONCE, but I can't achieve this, hence the question.
My current effort:
I've tried to subscribe to one of latest steps in redmine installation
subscribe => [Exec['rails_migrations']]
and then import data, but the first step "create-project1" always notifies second step "import-issues", so it creates duplicated data.
And if run vagrant provision few times, the "import-issues" creates duplicates of this issues.
Here is my code:
exec {'create-project1':
subscribe => [Exec['rails_migrations']],
path => ['/usr/bin', '/usr/sbin', '/bin'],
creates => "$redmine_install_dir/.data_loaded",
command => "curl WHICH_CREATES_PROJECT && touch $redmine_install_dir/.data_loaded",
notify => [Exec['import-issues']],
} ->
exec {'import-issues':
path => ['/usr/bin', '/usr/sbin', '/bin'],
command => "curl WHICH_IMPORTS_ISSUES",
refreshonly => true,
}
Question:
How to configure those Exec commands to run in chain and ONLY ONCE?
Im also thinking about extending this chain to 5 commands in near future, so keep that in mind.
you were almost there with 'ONLY ONCE' - Puppet has onlyif properties that you can include in your exec block to test if a file already exists or not.
you could then do something like
exec {'create-project1':
subscribe => [Exec['rails_migrations']],
path => ['/usr/bin', '/usr/sbin', '/bin'],
onlyif => "test ! -f $redmine_install_dir/.data_loaded"
command => "curl WHICH_CREATES_PROJECT && touch $redmine_install_dir/.data_loaded",
notify => [Exec['import-issues']],
which test on the existence of the $redmine_install_dir/.data_loaded- you should be able to play a bit with that to achieve what you want
Normally I run my tests with parallel_cucumber which runs different features in parallel using parallel_test gem. I want to setup a rake task that will run using different profiles and run the features within each task in parallel.
I have setup my Rakefile this way:
namespace :features do
Cucumber::Rake::Task.new(:basket) do |t|
t.profile = "basket"
end
Cucumber::Rake::Task.new(:fruits) do |t|
t.profile = "fruits"
end
Cucumber::Rake::Task.new(:veggies) do |t|
t.profile = "veggies"
end
task :all => [:basket, :fruits, :veggies]
end
When I run "rake features:all" it will run each task in sequence(as expected/desired) but will run the features within each task one at a time(not desired). I would like to keep each task running in sequence but would like the features within each task to run in parallel. Is this possible? If not is there a way this can be done?
As always your help is much appreciated.
Rake offers multitask. You could either
Changing task to multitask in the rakefile:
multitask :all => [:basket, :fruits, :veggies]
use -m option in the command line:
rake -m features:all
Have a look at the parallel_tests gem. It allows you to run your features in parallel. While the typical use case is to run all of your features, you are able to run specific rake tasks in parallel. See the documentation for more details.
I've recently updated my capistrano gem to version 3.1.0, and since then cap production deploy passes fine, but the target deploy:restart is not called.
My server is deployed on Ubuntu 12.10 on Amazon EC2.
Why could that be?
Capistrano 3 no longer runs that task by default as many app servers don't require it. Add this to your config/deploy.rb:
after 'deploy:publishing', 'deploy:restart'
From the release notes:
Breaking changes:
deploy:restart task is no longer run by default.
From this version, developers who restart the app on each deploy need to declare it in their deploy flow (eg after
'deploy:publishing', 'deploy:restart').
Please, check 4e6523e for more information. (#kirs)
If you are using namespaces, you can also do the following:
namespace :deploy do
desc "My description"
task :my_task do
#do something
end
after :publishing, :my_task
end
In my case, in file 'production.rb' I had this roles: %w{web, app, db} which prevent block on roles(:app), in: :sequence, wait: 5 do in file "deploy.rb" from correct execution.You see, it needs to be roles: %w{web app db}
I'm using Mina (a simpler alternative to Capistrano) to deploy my ruby websites, and I am trying to run some tasks once the current symlink has been updated.
So far, here's what I have in my deploy.rb file:
desc "Deploys the current version to the server."
task :deploy => :environment do
deploy do
invoke :'git:clone'
invoke :'deploy:link_shared_paths'
invoke :'bundle:install'
to :launch do
invoke :restart
end
end
end
desc "Manually restart Thin web server"
task :restart do
in_directory "#{deploy_to}/current" do
queue! %[bundle exec thin restart -C "#{thin_yml}"]
end
end
My problem is that when Mina hits the to :launch block, the current symlink has not yet been updated, so either it does not exist (if it is the 1st deployment for this project) or it's still pointing to the n-1 release (and thus, the server uses an outdated version of the project).
So I'd like to be able to invoke my :restart task once the new release has been moved to the release directory and the current symlink has been updated.
I think it's a bug of Mina. in_directory seems to not work properly when used inside a to context. A quick and dirty workaround would be adding #commands[:default] = commands(#to) at the end of the in_directory block.
desc "Manually restart Thin web server"
task :restart do
in_directory "#{deploy_to}/current" do
queue! %[bundle exec thin restart -C "#{thin_yml}"]
#commands[:default] = commands(#to)
end
end
I generate two different sets of DLL files from my .sln by modifying the .csproj files to include an extra compilation symbol. I'm using rake to build the solution, and have the following Build task:
#==========================================================
desc "Builds the DPSF.sln in Release mode."
msbuild :Build do |msb|
puts 'Building the DPSF solution...'
msb.properties :configuration => :Release
msb.targets [:Clean, :Rebuild]
msb.solution = DPSF_SOLUTION_FILE_PATH
msb.parameters "/nologo", "/maxcpucount", "/fileLogger", "/noconsolelogger"
msb.verbosity = "quiet" # Use "diagnostic" instead of "quiet" for troubleshooting build problems.
# Delete the build log file if the build was successful (otherwise the script will puke before this point).
File.delete('msbuild.log')
end
I then try to generate both sets of DLL files using:
desc "Builds new regular and AsDrawableGameComponent DLLs."
task :BuildNewDLLs => [:DeleteExistingDLLs, :Build, :UpdateCsprojFilesToBuildAsDrawableGameComponentDLLs, :Build, :RevertCsprojFilesToBuildRegularDLLs]
You can see that I call :Build twice here. The problem is that only the first one runs. If I copy/paste my :Build target and call it :Build2 and change :BuildNewDLLs to call :Build2 the second time, then everything works fine. So how can I make it so that I can call the :Build target multiple times from within the :BuildNewDLLs target?
Thanks in advance.
I know this is an old question, but I just spent 15 minutes figuring this out, so for the sake of documentation, here goes:
You can call reenable from within the same task that you wish to reenable. And since the task block yields the current task as first argument, you can do:
task :thing do |t|
puts "hello"
t.reenable
end
And now this works:
rake thing thing
Rake will, by default, ensure that each rake task is executed once and only once per session. You can re-enable your build task with the following code.
::Rake.application['Build'].reenable
That will allow it to be re-executed in the same session.