-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix multiple issues relating to variables #70
Conversation
+1 |
I just removed misleading info from https://github.com/sosedoff/capistrano-unicorn/wiki/Using-capistrano-unicorn-with-multistage-environment regarding |
@aspiers we can use "docs" folder to store manuals, better than on-site wiki |
Rebased after merge of #69. |
@sosedoff Agreed! Luckily there is only one wiki page at the moment, and this pull request makes that obsolete anyway ... |
Any feedback? |
This all looks good to me, after a quick code review. It's all straightforward. |
@sfsekaran Thanks! Should I merge then? Not sure what the protocol is for how many +1s are required for this. |
OK, I think I'm done now. I ended up making several more changes, including a fix for #7, i.e. auto-detection of the pid file path from the unicorn config. I also added a Would greatly appreciate someone testing this branch, since there are quite a lot of changes and I could have broken something (although I took great care not to!) |
Hmm, I'll have to rebase this now that we have a test suite :-/ |
It would be awesome if you had time to write a few tests!
Sathya Sekaran On Thu, Aug 29, 2013 at 4:42 PM, Adam Spiers notifications@github.com
|
Already working on it :) |
Almost finished this yesterday, will push soon ... |
… variables This is the first step towards resolving sosedoff#46 and sosedoff#64.
This contributes towards resolving sosedoff#46 and sosedoff#64.
This is the final commit in the series which fixes sosedoff#46.
…s to unicorn Fixes sosedoff#64 via: set :unicorn_options, '-N' (although I'm not sure why you'd need this over setting :unicorn_rack_env to 'none').
Accurate docs for this is now coupled to the release, and should not live in the wiki, since claims about app_env in older versions may or may not be accurate, but they certainly aren't at this point in the code base.
Grouping all path calculations together improves legibility and maintainability.
Also re-order and re-structure assignment and display of variables for legibility.
OK, this has pretty thorough tests now, and I fixed a few minor issues whilst writing them. So I'm pretty confident this is good to merge :) |
Please can someone review and merge? |
@aspiers Have you tested this out on a production env yet? It all looks good to me otherwise. |
Yes I'm using it to deploy two public apps (although they are tiny and low risk). The new |
@aspiers Sounds great. Merging. |
fix multiple issues relating to variables
@sosedoff When you get a chance--it's time for that gem release to v0.2.0. |
@aspiers Thank you for all the hard work! This was an excellent effort. I especially appreciate the attention to documentation here. |
@sfsekaran Thanks :) I hate the idea of anyone else being confused by the docs in the same way I was, so I had to fix them :) |
When i run test suite i get 4 failures even though travis build passes. Ruby 2.0.0p247:
|
This means the pid file auto-detection, which involves running |
Maybe Travis uses Unicorn. :'D On Friday, September 6, 2013 at 3:34 PM, Adam Spiers wrote:
|
I added debug into build steps, there is no unicorn installed. See the build https://travis-ci.org/sosedoff/capistrano-unicorn/jobs/11100220 |
Weird, I don't know why yours is failing then. But it should be really easy for you to debug - the code is super simple! |
Any movement on this? It bothers me--I see four failures locally as well. |
@sfsekaran I do not see any failures, just warnings, e.g.
I did a git bisect, and the warnings arise from 9c355a5 in #74 which you merged into |
It's not right to mock $?.success?, because $? can be nil at the time the expectation is set, resulting in errors like: An expectation of :success? was set on nil. Called from /home/adam/.GIT/3rd-party/capistrano-unicorn/spec/config_spec.rb:36:in `block Instead we simply ensure that $? is set to an appropriate value. This may or may not fix the failures that some people have been seeing (mentioned in sosedoff#70).
rails_env
/unicorn_env
/app_env
are redundant or undocumented #46