Skip to content
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

Merged
merged 20 commits into from
Sep 6, 2013

Conversation

aspiers
Copy link
Contributor

@aspiers aspiers commented Aug 20, 2013

@modojenkins
Copy link

+1

@aspiers
Copy link
Contributor Author

aspiers commented Aug 22, 2013

I just removed misleading info from https://github.com/sosedoff/capistrano-unicorn/wiki/Using-capistrano-unicorn-with-multistage-environment regarding app_env. However in future I think we should avoid storing docs in the wiki and instead store them in the git repo, because it's crucial that docs are coupled to the code they are documenting. When a commit changes the code, it must also update the corresponding docs. If they are in different places they can get out of sync far too easily.

@sosedoff
Copy link
Owner

@aspiers we can use "docs" folder to store manuals, better than on-site wiki

@aspiers
Copy link
Contributor Author

aspiers commented Aug 22, 2013

Rebased after merge of #69.

@aspiers
Copy link
Contributor Author

aspiers commented Aug 22, 2013

@sosedoff Agreed! Luckily there is only one wiki page at the moment, and this pull request makes that obsolete anyway ...

@aspiers
Copy link
Contributor Author

aspiers commented Aug 23, 2013

Any feedback?

@sfsekaran
Copy link
Contributor

This all looks good to me, after a quick code review. It's all straightforward.

@aspiers
Copy link
Contributor Author

aspiers commented Aug 24, 2013

@sfsekaran Thanks! Should I merge then? Not sure what the protocol is for how many +1s are required for this.

@aspiers
Copy link
Contributor Author

aspiers commented Aug 24, 2013

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 NEWS.md file since all these changes could get a bit confusing, and are not 100% backwards-compatible.

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!)

@aspiers
Copy link
Contributor Author

aspiers commented Aug 29, 2013

Hmm, I'll have to rebase this now that we have a test suite :-/

@sfsekaran
Copy link
Contributor

It would be awesome if you had time to write a few tests!

Sathya Sekaran
Sent from Mailbox for iPhone

On Thu, Aug 29, 2013 at 4:42 PM, Adam Spiers notifications@github.com
wrote:

Hmm, I'll have to rebase this now that we have a test suite :-/

Reply to this email directly or view it on GitHub:
#70 (comment)

@aspiers
Copy link
Contributor Author

aspiers commented Aug 29, 2013

Already working on it :)

@aspiers
Copy link
Contributor Author

aspiers commented Sep 2, 2013

Almost finished this yesterday, will push soon ...

Adam Spiers added 13 commits September 2, 2013 21:42
… variables

This is the first step 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.
@aspiers
Copy link
Contributor Author

aspiers commented Sep 2, 2013

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 :)

@aspiers
Copy link
Contributor Author

aspiers commented Sep 6, 2013

Please can someone review and merge?

@sfsekaran
Copy link
Contributor

@aspiers Have you tested this out on a production env yet? It all looks good to me otherwise.

@aspiers
Copy link
Contributor Author

aspiers commented Sep 6, 2013

Yes I'm using it to deploy two public apps (although they are tiny and low risk). The new unicorn:show_vars task helps build confidence that it is calculating the right values, before you run any task which actually deploys anything. But the test suite is also pretty comprehensive at this point.

@sfsekaran
Copy link
Contributor

@aspiers Sounds great. Merging.

sfsekaran added a commit that referenced this pull request Sep 6, 2013
fix multiple issues relating to variables
@sfsekaran sfsekaran merged commit 887b69c into sosedoff:master Sep 6, 2013
@sfsekaran
Copy link
Contributor

@sosedoff When you get a chance--it's time for that gem release to v0.2.0.

@sfsekaran
Copy link
Contributor

@aspiers Thank you for all the hard work! This was an excellent effort. I especially appreciate the attention to documentation here.

@aspiers aspiers deleted the variables branch September 6, 2013 10:58
@aspiers
Copy link
Contributor Author

aspiers commented Sep 6, 2013

@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 :)

@sosedoff
Copy link
Owner

sosedoff commented Sep 6, 2013

When i run test suite i get 4 failures even though travis build passes. Ruby 2.0.0p247:

Failures:

  1) CapistranoUnicorn::CapistranoIntegration loaded into a configuration testing variables app paths app in current_path it should behave like an app in path should auto-detect pid file from primary unicorn config
     Failure/Error: @configuration.fetch(:unicorn_pid).should == pid_file
       expected: "/path/to/pid/from/config/file"
            got: "/path/to/myapp/tmp/pids/unicorn.pid" (using ==)
     Shared Example Group: "an app in path" called from ./spec/capistrano_integration_spec.rb:93
     # ./spec/capistrano_integration_spec.rb:60:in `block (6 levels) in <top (required)>'

  2) CapistranoUnicorn::CapistranoIntegration loaded into a configuration testing variables app paths app in current_path it should behave like an app in path should auto-detect pid file from stage unicorn config
     Failure/Error: @configuration.fetch(:unicorn_pid).should == pid_file
       expected: "/path/to/pid/from/stage/config/file"
            got: "/path/to/myapp/tmp/pids/unicorn.pid" (using ==)
     Shared Example Group: "an app in path" called from ./spec/capistrano_integration_spec.rb:93
     # ./spec/capistrano_integration_spec.rb:60:in `block (6 levels) in <top (required)>'

  3) CapistranoUnicorn::CapistranoIntegration loaded into a configuration testing variables app paths app in a subdirectory it should behave like an app in path should auto-detect pid file from primary unicorn config
     Failure/Error: @configuration.fetch(:unicorn_pid).should == pid_file
       expected: "/path/to/pid/from/config/file"
            got: "/path/to/myapp/mysubdir/tmp/pids/unicorn.pid" (using ==)
     Shared Example Group: "an app in path" called from ./spec/capistrano_integration_spec.rb:103
     # ./spec/capistrano_integration_spec.rb:60:in `block (6 levels) in <top (required)>'

  4) CapistranoUnicorn::CapistranoIntegration loaded into a configuration testing variables app paths app in a subdirectory it should behave like an app in path should auto-detect pid file from stage unicorn config
     Failure/Error: @configuration.fetch(:unicorn_pid).should == pid_file
       expected: "/path/to/pid/from/stage/config/file"
            got: "/path/to/myapp/mysubdir/tmp/pids/unicorn.pid" (using ==)
     Shared Example Group: "an app in path" called from ./spec/capistrano_integration_spec.rb:103
     # ./spec/capistrano_integration_spec.rb:60:in `block (6 levels) in <top (required)>'

@aspiers
Copy link
Contributor Author

aspiers commented Sep 6, 2013

This means the pid file auto-detection, which involves running unicorn -c on a temporary config file, is failing. Maybe you don't have unicorn installed? There is no development dependency on it, and there probably should be ... which begs the question why the Travis runs are succeeding. Weird.

@sfsekaran
Copy link
Contributor

Maybe Travis uses Unicorn. :'D

On Friday, September 6, 2013 at 3:34 PM, Adam Spiers wrote:

This means the auto-detection, which involves running unicorn -c on a temporary config file, is failing. Maybe you don't have unicorn installed? There is no development dependency on it, and there probably should be ... which begs the question why the Travis runs are succeeding. Weird.


Reply to this email directly or view it on GitHub (#70 (comment)).

@sosedoff
Copy link
Owner

sosedoff commented Sep 7, 2013

I added debug into build steps, there is no unicorn installed. See the build https://travis-ci.org/sosedoff/capistrano-unicorn/jobs/11100220

@aspiers
Copy link
Contributor Author

aspiers commented Sep 7, 2013

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!

@sfsekaran
Copy link
Contributor

Any movement on this? It bothers me--I see four failures locally as well.

@aspiers
Copy link
Contributor Author

aspiers commented Sep 17, 2013

@sfsekaran I do not see any failures, just warnings, e.g.

An expectation of :success? was set on nil. Called from /home/adam/.GIT/3rd-party/capistrano-unicorn/spec/config_spec.rb:36:in `block (6 levels) in <top (required)>'. Use allow_message_expectations_on_nil to disable warnings.

I did a git bisect, and the warnings arise from 9c355a5 in #74 which you merged into master.

aspiers pushed a commit to aspiers/capistrano-unicorn that referenced this pull request Sep 17, 2013
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).
@sfsekaran
Copy link
Contributor

@aspiers Note that I merged #74 fairly recently, and I saw four failures before I paired on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants