First deploy fails when using this gem about capistrano-puma

[seuros]

I can make so that if puma is not running :

1. Run it
2. Do nothing

What do you think is better ?

[shaneog]

I think 1 is better. Also, can you hook puma:config in somewhere or provide directions as to when is best to hook it into the deploy process?

[seuros]

Yes sure.

[seuros]

@shaneog, can you try now with the master branch ?

[shaneog]

I'll try it out later today

[shaneog]

Sorry for the delay.

On a new build, the check_puma fails. It needs to run after the Capistrano directory setup stage.

DEBUG [25b2f33d] Running /usr/bin/env [ -f /webapps/c3-puma-test/shared/config/puma.rb ] on ec2-XXXXXXXXX.sa-east-1.compute.amazonaws.com
DEBUG [25b2f33d] Command: [ -f /webapps/c3-puma-test/shared/config/puma.rb ]
DEBUG [25b2f33d] Finished in 0.727 seconds with exit status 1 (failed).
 WARN puma.rb NOT FOUND!
DEBUG Uploading /webapps/c3-puma-test/shared/config/puma.rb 0.0%
scp: /webapps/c3-puma-test/shared/config/puma.rb: No such file or directory

Suggestion: Change before 'deploy:check', 'puma:check' to after 'deploy:check', 'puma:check' which will allow Capistrano to set up the required shared directories.
Also, add a section to the README specifying the required shared directories. (i.e. tmp/pids tmp/sockets log)

[shaneog]

Suggestion: Change the default puma.rb shared directory. At the moment I must set it manually unless I want to share my entire /config directory.
There should be sane defaults

[shaneog]

Also, it would be nice if the default restart option (after finished) was configurable, as personally I'd rather do a phased restart

[seuros]

Thank you for your input Shane,

Also, add a section to the README specifying the required shared directories. (i.e. tmp/pids tmp/sockets log)

• These are common Capistrano shared folders. I will add a note in the next push.

Change the default puma.rb shared directory. At the moment I must set it manually unless I want to share my entire /config directory.

• you can set it with set :puma_conf

Also, it would be nice if the default restart option (after finished) was configurable, as personally I'd rather do a phased restart

• That in my next TODO list, it will switch to phased restart automatically if it detect that number of worker is 2+.

Ps : I'm currently adding recipes for monit and nginx(vhost)

[shaneog]

Great, thanks. Good work.

The only thing that I have an issue with it the conf file path, I know I can set it and I will, but IMVHO you should set a sane default for this. At the moment the only way it will work "out of the box" is by sharing your entire config directory, which is not advisable.

[seuros]

No you don't. puma.rb don't need to be present in the current_path . The script use it directly from the shared path.
The only shared file i have in my project is database.yml

[shaneog]

Sorry, there seems to be a misunderstanding. I'll clarify:

The default path to create/use puma.rb is "#{shared_path}/config/puma.rb"

However on a default Capistrano/Rails project the #{shared_path}/config directory does not exist and is not created by the Capistrano deploy:check task, thus your task puma:check (which calls template_puma) fails because it can't write to a directory that does not exist.

So I must either

• add config to the linked_dirs list which will share my project config directory, which is undesirable

or

• manually set the :puma_conf variable which negates the concept of having sane defaults

In my case I have the :puma_conf variable set to "#{shared_path}/puma.rb"

[seuros]

That make sense , i will push change shortly and please test.
Current users will have the puma.rb regenerated in the new location

What about pids , tmp and logs folder ?

[shaneog]

I think the pids, tmp and log folders are fine as they use "standard" linked directories, but it's worth noting in the README what you need to have in your linked_dirs list

[masterkain]

Phased restart should be default in my opinion on restart, if puma knowns that it can't do a phased, it will fallback to the normal one.

[masterkain]

I'm also finding that issuing a cap staging puma:stop will effectively stop puma, but the puma.state file hangs around as it's not deleted, making tasks such as cap staging deploy cap staging puma:start, etc. fail due to bundle exec pumactl -S /home/ubuntu/apps/myapp-rails/shared/tmp/pids/puma.state restart

$ cap staging puma:stop
...
Command stop sent success

$ cap staging puma:start
...
 INFO [dabcd7ed] Running ~/.rvm/bin/rvm ruby-2.1.0-preview2@myapp do bundle exec pumactl -S /home/ubuntu/apps/myapp-rails/shared/tmp/pids/puma.state restart on 162.243.255.230
cap aborted!
bundle stdout: Nothing written
bundle stderr: Nothing written

I'm not sure if it's a puma problem, but the state file doesn't get cleaned up, as of late I never met this while using cap 2 with puma default task.