Is there a way to mount Yard (http://yardoc.org/guides/index.html) server on heroku ?
I did not find anything in the doc that explains how to do it.
Thanks a lot
This may have pitfalls I haven't uncovered yet (e.g. Yard caches its output files somewhere, given Heroku may often wipe the filesystem and re-slug it, you will lose the cache files and have to be regenerated), but it generally works and is very simple.
Create a new folder on your hard drive somewhere (I used ~/Sites/yard-on-heroku)
Create a new Gemfile in there, listing the gems you want to be available (if they aren't in the standard Heroku install). I used the following:
source 'https://rubygems.org'
gem 'sinatra'
gem 'rails'
gem 'yard'
Run bundle install to install the gems.
Create a file called Procfile and put the following in it:
web: yard server -p $PORT -g
Create a new git repository with git init
Commit your files to it (Gemfile*, Procfile)
Create a Heroku app with heroku create
Push your repo to Heroku with git push heroku master
And that's it. If you go to the Heroku URL given when you created the site in step 7, you'll see Yard running with all the gems available too it. If you want to specifically only show the gems listed in the Gemfile rather than all the Gems available by default including the ones in your Gemfile, then you can use -G instead of -g in the Procfile.
(my first ever answer on StackOverflow, so hope it's OK - any advice on improvements, gratefully received).
I wrote a nice tutorial with my solution to this problem here: http://benradler.com/blog/2014/05/27/deploy-yard-documentation-server-to-heroku/
Related
I am using Cocoapods, and one of the libraries I use is ZUUIRevealController, currently the version is 0.9.6 in Cocoapods, which is not the latest one, if I want to create my own pods for that, what are the steps for doing it?
Thanks!
To update for everyone:
OK, so all the cocoapods are held inside a big specs repository Here. We want to go down to the ZUUIRevealController part of the repo. We can see just the 0.9.6 which is how cocoapods knows what version it is.
So, fork the cocoa pods spec repository and open the folder in SublimeMate Pro. You're going to want to add the next version to this folder, so let's say you were going to use 0.9.7. Make a folder for that and copy it over ZUUIRevealController.podspec from version 0.9.6.
The new podspec will need some changing as it refers to the git tag "v0.9.6" and ideally you want to use 0.9.7. Now I've checked for you, there isn't a 0.9.7 which means you'll have to create an issue asking for a new tag, which someone has already done.
With the new tag in the repo you can move that tag into your podfile. Then in the Specs directory run pod specs lint ZUUIRevealController which will tell you whether your podspec has passed or failed linting. If you don't do this it will be done automatically on your pull request, and it's likely that it will be me telling you how to fix it.
If it passes, you can then commit that change and submit a pull request to the Cocoapods/Specs repo on github.
To update for just you:
in your podspec, you can set the commit that you want to override the normal podfile's commit with ( for example )
pod 'ZUUIRevealController', :git => 'git://github.com/orta/ZUUIRevealController', :commit => 'd4c9d810e0f0d1982472c8d1d5469841b09854ab'
This may require deleting your Pods directory first as it might have cached the url / commit.
I need to switch from Composer (which is used by Symfony2 by default) to Git submodules.
I thought I could just add the desired submodules to the desired locations, thus overwriting the current version which was installed by Composer.
But when I use git submodule add, it says:
'vendor/twig/twig' already exists in the index
So I tried:
git rm vendor/twig/twig
and tried to add the submodule again, same error.
What am I doing wrong?
I'm founder and ceo of cloudControl. Currently composer does break our image building process because it interferes with the logic we have to detect submodules in some way. The team is aware of this problem and working to fix the underlying issue.
I'm working for cloudControl and we've been lately inquiring into this issue.
Regarding the original problem, you proposed already a right solution for replacing the composer packages by git submodules, it was just a git commands issue. But doing this doesn't make much sense, as long as these git submodules are identical to the Composer packages and your php code is still hanging on the autoload.php provided by Composer.
We don't process internally Composer yet, their files are just added into the repository and the php code requirements make the rest. However we do process git submodules, so if you want to make a real switch from Composer to Git Submodules, the best option is getting rid of Composer files (vendor folder and composer.* files), adding git submodules wherever you want and handling again the php dependencies . Thus everything should work fine and you'd have switched completely to git submodules.
Native support for Composer is in our future plans.
The problem was that i had to actually delete and git-remove the repository first.
i.e. for twig what i did in the end was:
git rm -r vendor/twig/*
rm -r vendor/twig/*
git add vendor/.
git submodule add git://github.com/fabpot/Twig.git vendor/twig/twig
git submodule add https://github.com/fabpot/Twig-extensions.git vendor/twig/extensions
Now i have twig and twig extensions as a git submodule and can use it in my cloud application.
I tried rake gem:unpack but I get task not found. I would like to have refinery gems in my /vendor directory to be able to see the never ending views and partials and may be modify them.
I'm still learning how to do things the "Rails way", but I feel your need to have the files in a directory that's easy to see. One command I found that will dump in vendor in the local project is bundle install --deployment. You'll need to run this after initially doing a bundle install.
run bundle package
more here: http://gembundler.com/bundle_package.html
Considering putting RVM into production (light duty) on a new machine. But I'm not visualizing how it will work if a user isn't logged in. RVM has been installed into /usr/local/rvm/bin/rvm so it is available to "everyone".
If server restarts and is at login screen and background daemons are serving apache/rails, etc. and no .bashrc, etc. have loaded...how/where do we specify which of RVM's Rubies to load?
Perhaps somewhere in Phusion's Passenger?
who manages these gemsets? are they shared?
You can use RVM's wrapper command to generate scripts that load up the correct RVM environment before executing the necessary binaries. The format is:
rvm wrapper [ruby_string] [wrapper_prefix] [binary[ binary[ ...]]]
For example, to create a binary named system_unicorn that loads ruby-1.9.2-p180 and then executes unicorn, use the following:
rvm wrapper ruby-1.9.2-p180 system unicorn
You can pass multiple binaries to create wrappers for. For example, to create wrappers for both unicorn and god, run
rvm wrapper ruby-1.9.2-p180 system unicorn god
ruby_string can be anything you can pass to rvm use, and thus can contain gemsets as well; for example, to create myapp_unicorn for the gemset my_app_gemset, use:
rvm wrapper ruby-1.9.2-p180#my_app_gemset myapp unicorn
When you install Passenger these days, it automatically creates a wrapper for it's ruby (pretty sure it calls it passenger_ruby) that loads up the correct version of Ruby (the one you're using when you install it). You can use config/setup_load_paths.rb to specify a gemset--see this Stack Overflow answer.
I've dealt with this in the past by running all jobs with a user that has rvm set up. It does add complexity to many simple jobs because you have to make sure that rvm is loaded. If you need to run commands as root AND use rvm, you can use the rvmsudo command.
You can also install RVM systemwide as root:
https://rvm.beginrescueend.com/rvm/install/
1) root installs the ruby versions and gems under RVM if you install them globally
(read the RVM readme -- there seem to be possible problems when installing globally!)
2) if you're on UNIX, each of your system processes gets started as a particular user,
e.g. on LINUX through the init-scripts in /etc/init.d/ ... while the processes are
created as a particular user, the mapping of user names to UID/GID, the home directory,
and login-shell are looked up in the /etc/passwd file
-- that is where the login shell (e.g. bash) is defined for a particular user.
So, coming back to your statement:
If server restarts and is at login screen and background daemons are serving apache/rails, etc.
and no .bashrc, etc. have loaded...how/where do we specify which of RVM's Rubies to load?
You see the problem with that statement?
When the server starts, and the background processes are started, each of them gets started as a particular user, with a particular login shell and with a particular home directory.
RVM will need that you have your login shell set to /bin/bash -- otherwise it couldn't set up the RVM environment for any of the processes that are run by that particular user. e.g. RVM will not work if you use /bin/nologin as the default shell.
Problem1:
That's a security problem of course! In general, daemons should not have a shell set for security reasons.
Problem2:
You don't want to make high-powered tools available to somebody breaking into your server - that's why you shouldn't have cc and other tools on a production server - that's why you should not compile your Rubys and Gems on the production server, but rather copy the .rvm directory onto the production servers...
Problem3: (more general)
The way RVM manages all it's Ruby and Gem versions is very very kludgy approach to version management..
Using special features of one particular login shell to facilitate the version management is not a good idea IMHO - sure there is nothing better at the moment, but in the old days, the idea behind Lude was a far better approach to install different versions of software:
http://www.iro.umontreal.ca/contrib/lude/lude2_toc.html
Conclusion:
So as I mentioned in a previous post, I highly recommend to set up RVM a normal user account to run your Ruby and Rails processes and to set up that one account with /bin/bash as the login shell and to copy your .rvm directory from your dev-server to your production machines via scp or rsync -- it's the better and safer approach.
I had a similar problem, where I want to deploy the ruby version and all associated gems to the production machines...
Because of the reasons outlined in my other post, I chose to go with a local RVM install. I have a user "deploy" on both my dev-servers and my production servers.
I would highly recommend that you use either "rsync' or 'scp -rp' to copy the complete subdirectory ~/.rvm to the target machine (remember that you don't want to have cc and other tools on a production server!)
One important Gotcha:
be sure that you use the identically named user account on all machines, if you replicate the .rvm directory!
I noticed that the internal book-keeping of RVM keeps track of some environment variables during installation of Ruby versions and gems, and that it keeps track in particular of the name of the user account that was used, and the path to the users's home directory. Beats me why they don't use $HOME and $USER , which are standard on all UNIXes.. seems like a real bug in RVM to me.
if you use the same user account for all machines, it will work just fine.
e.g. I use a user "deploy" which has the .rvm directory and which owns the running processes.
UPDATE
if you use rsync or scp to sync your deployment account, the downside is that you need to restart your servers, e.g. unicorn, manually.
Another promising way of deploying RVM and Rails apps is to deploy to one machine, where bundle update is run, and then create an RPM out of the whole deployment account, which is then installed via rpm -Uhv or a private yum repository onto all the nodes. Advantage here is that the services on the nodes can be easily restarted via a %post action in the RPM.
I already have all the gems, and each time I do
rails trytry02
cd trytry02
bundle install
to create the Gemfile.lock, it takes a long time to fetch data from rubygems.org. But I noticed that if I do a
rails g scaffold foo name:string
before doing the bundle install, then the Gemfile.lock is created very fast. Is there a way to create it fast but not using rails g scaffold?
Douglas is correct, this is because bundle install is doing a round trip to rubygems.org to look for newer versions. If you want to just use the local versions...
bundle install --local
But - why are you generating your Gemfile.lock so often that this is an issue? Your Gemfile.lock should be under version control, ie. part of your project, and so should only change occasionally.
Try to change https to http in the Gemfile and see if this increases its speed.