My root capistrano has a task that dumps the database: cap production dump or cap staging dump will dump the database.
Now, I want to define a task in staging that will run this task on production.
I could do
desc 'Updates the database of acceptance with the latest production database'
task :update_db do
run_locally do
execute :cap, 'production', 'dump'
# move dump-file from production, via local, to acceptance
end
on roles(:db) do
execute :rake, 'db:data:load'
end
end
But running a cap task from a cap task via a shell feels ugly and
fragile.
I found
Calling a multistage capistrano task from within a capistrano task
but that does not work, probably because its a solution for an old
version of Capistrano.
Is there a way to run a certain capistrano task on a certain "stage"
from within Capistrano?
Related
Im working on a simple deployment pipeline with azure devops. I created a deployment pipeline running on a self hosted ubuntu deployment group.
The pipeline looks like this:
Download artifacts from CI pipeline (created with dotnet publish)
Stop running deployment
Unzip the ASP.NET Core Web API to the deployment directory
Run new deployment with dotnet MyApp.dll
The first two steps work as expected. However, when the dotnet My App.dll command is run, the process runs for 10 seconds with following "error" message being printed at the end:
The STDIO streams did not close within 10 seconds of the exit event from process '/usr/bin/bash'. This may indicate a child process inherited the STDIO streams and has not yet exited.
The deployment task is successful despite the message and the app not running. I tried to work around this feature by using nohup & and relocating the command output. After some research I found that all processes started by a pipeline agent are stopped after the agent's work is done - meaning this behaviour is intended and my understanding of azure deployments/agents is wrong.
How do I deploy and run my app in an automated way on my own ubuntu machine using azure devops pipelines?
How do I deploy and run my app in an automated way on my own ubuntu machine using azure devops pipelines?
You are already on the right way.
All the process launched in the pipeline will be finished/clean up in “Finalize Job” step when the pipeline is over.
If you don't want the process to be closed, please try set variable Process.clean= false to stops the "finalize job" step from killing all processes.
But when you create a new pipeline next time, you need to close the app before starting it.
I have a task that runs on deployment of either staging or production. Ideally I would like to pass in some arguments to the task depending on whether I am deploying to production or staging.
These tasks are within lib/capistrano/tasks/.
Within the .rake file how can I access the environment so I can determine what I need to set as the flag.
I have no issues setting the flag just not sure how I can access the environment.
If anyone can help it would be very much appreciated.
Depending on how you are invoking the Rake task, you should be able to set an environment variable based on the value of fetch(:stage). For example, something like:
run "APP_ENV=#{fetch(:stage)} bundle exec rake my:task"
The above code is untested, but should be basically what you are looking for.
which file is referenced by Capistrano 2 to perform a rollback?
I am using chef's deploy_revision and this create a cache of the revisions under
/var/chef/cache/revision-deploys/path/to/myapp
I was testing Capistrano 2 in the same project, trying to figure out which one i choose for the deployment. i did this to perform a rollback
cap <stagename> deploy:rollback
but it ended up rolling back to a revision which is not in line with the one in the cache cache copy of the revision list.
I may be wrong to expect Capistrano to follow what was there for the chef. But i am trying to straighten this rollback in Cap2.
the application service fails to start properly
Inside the deploy.rb file, i placed a task like this
after "deploy", "deploy:restart_app"
the task looks like this:
task :restart_app, :roles => :web do
run "sudo /etc/init.d/abc restart", :shell => :bash
end
but when the deploy is completed if do a status for my app (abc), it says "process dead and pid exist". this also true the pid file exist in /var/run/abc.pid
manual test execution of sudo /etc/init.d/abc restart as the deploy user, work fine.
I must be missing something with Capistrano, because I've just started writing capfiles and I'm looking at tons of duplicated code. Consider this
role :dev, "dev1", "dev2"
role :prod, "prod1", "prod2"
desc "Deploy the app in dev"
task :deploy_dev, :roles => :dev do
run "sudo install-stuff"
end
desc "Deploy the app in prod"
task :deploy_prod, :roles => :prod do
run "sudo install-stuff"
end
IMO it's totally reasonable to want to run the exact same task in dev or prod, but from what I can tell, Capistrano would have me write 2 tasks just to specify the different nodes...
Seems like if you could refer to roles on the CLI like
cap deploy dev
cap deploy prod
there could be a single definition of the 'deploy' task in the capfile, as opposed to a duplicated one for each set of servers.
Is there a way to write a task once and specify the role dynamically?
Have a look at the multistage extension. While fairly easy to set up the tasks you need yourself, the multistage extension will do it all for you.
If you'd rather do it yourself, see the calling tasks section of the handbook. The trick is that you can invoke different tasks in order from the command line.
I have a task that needs to run in QA and prod, but not dev. The task is to stop a clustered application. The problem is that the dev servers aren’t clustered and the task to stop the cluster fails on these servers. Is there a way to handle this?
We used to have that issue as well. When the task ran to stop the cluster, it would fail in dev:
The system cannot find the path specified
C:\Windows\Sysnative\Cluster.exe /cluster:server resource "Company Name Product" /offline
To get this to work, we can move the cluster commands to variables instead of directly in the task. That way we can have the dev version of stopping the cluster just do a no-op: cmd /exit. The QA version will run the real cluster stop command.
Task:
Dev Server Variable Group:
QA Server Variable Group: