Merge pull request #113 from Kriechi/various-fixes

Various fixes

Gemfile

@@ -1,5 +1,8 @@
 source "https://rubygems.org"
 
-gem "jekyll"
-gem "unindent"
-gem 'github-pages', github: 'github/pages-gem'
+# keep versions up-to-date with the actual GitHub Pages setup
+# https://pages.github.com/versions/
+
+# just do `bundle update` to get the latest version.
+
+gem 'github-pages'

Gemfile.lock

@@ -1,70 +1,126 @@
-GIT
-  remote: git://github.com/github/pages-gem.git
-  revision: a73cbe4d6b683e0ef1bbeefc01e10daac1498a65
-  specs:
-    github-pages (12)
-      RedCloth (= 4.2.9)
-      jekyll (= 1.4.2)
-      kramdown (= 1.2.0)
-      liquid (= 2.5.4)
-      maruku (= 0.7.0)
-      rdiscount (= 2.1.7)
-      redcarpet (= 2.3.0)
-
 GEM
   remote: https://rubygems.org/
   specs:
     RedCloth (4.2.9)
+    activesupport (4.2.0)
+      i18n (~> 0.7)
+      json (~> 1.7, >= 1.7.7)
+      minitest (~> 5.1)
+      thread_safe (~> 0.3, >= 0.3.4)
+      tzinfo (~> 1.1)
     blankslate (2.1.2.4)
-    classifier (1.3.4)
-      fast-stemmer (>= 1.0.0)
+    celluloid (0.16.0)
+      timers (~> 4.0.0)
+    classifier-reborn (2.0.3)
+      fast-stemmer (~> 1.0)
+    coffee-script (2.3.0)
+      coffee-script-source
+      execjs
+    coffee-script-source (1.8.0)
     colorator (0.1)
-    commander (4.1.5)
-      highline (~> 1.6.11)
+    execjs (2.2.2)
     fast-stemmer (1.0.2)
-    ffi (1.9.3)
-    highline (1.6.20)
-    jekyll (1.4.2)
-      classifier (~> 1.3)
+    ffi (1.9.6)
+    gemoji (2.1.0)
+    github-pages (32)
+      RedCloth (= 4.2.9)
+      github-pages-health-check (~> 0.2)
+      jekyll (= 2.4.0)
+      jekyll-coffeescript (= 1.0.1)
+      jekyll-mentions (= 0.2.1)
+      jekyll-redirect-from (= 0.6.2)
+      jekyll-sass-converter (= 1.2.0)
+      jekyll-sitemap (= 0.6.3)
+      jemoji (= 0.4.0)
+      kramdown (= 1.5.0)
+      liquid (= 2.6.1)
+      maruku (= 0.7.0)
+      mercenary (~> 0.3)
+      pygments.rb (= 0.6.0)
+      rdiscount (= 2.1.7)
+      redcarpet (= 3.1.2)
+      terminal-table (~> 1.4)
+    github-pages-health-check (0.2.1)
+      net-dns (~> 0.6)
+      public_suffix (~> 1.4)
+    hitimes (1.2.2)
+    html-pipeline (1.9.0)
+      activesupport (>= 2)
+      nokogiri (~> 1.4)
+    i18n (0.7.0)
+    jekyll (2.4.0)
+      classifier-reborn (~> 2.0)
       colorator (~> 0.1)
-      commander (~> 4.1.3)
-      liquid (~> 2.5.2)
-      listen (~> 1.3)
-      maruku (~> 0.7.0)
-      pygments.rb (~> 0.5.0)
-      redcarpet (~> 2.3.0)
-      safe_yaml (~> 0.9.7)
+      jekyll-coffeescript (~> 1.0)
+      jekyll-gist (~> 1.0)
+      jekyll-paginate (~> 1.0)
+      jekyll-sass-converter (~> 1.0)
+      jekyll-watch (~> 1.1)
+      kramdown (~> 1.3)
+      liquid (~> 2.6.1)
+      mercenary (~> 0.3.3)
+      pygments.rb (~> 0.6.0)
+      redcarpet (~> 3.1)
+      safe_yaml (~> 1.0)
       toml (~> 0.1.0)
-    kramdown (1.2.0)
-    liquid (2.5.4)
-    listen (1.3.1)
+    jekyll-coffeescript (1.0.1)
+      coffee-script (~> 2.2)
+    jekyll-gist (1.1.0)
+    jekyll-mentions (0.2.1)
+      html-pipeline (~> 1.9.0)
+      jekyll (~> 2.0)
+    jekyll-paginate (1.1.0)
+    jekyll-redirect-from (0.6.2)
+      jekyll (~> 2.0)
+    jekyll-sass-converter (1.2.0)
+      sass (~> 3.2)
+    jekyll-sitemap (0.6.3)
+    jekyll-watch (1.2.0)
+      listen (~> 2.7)
+    jemoji (0.4.0)
+      gemoji (~> 2.0)
+      html-pipeline (~> 1.9)
+      jekyll (~> 2.0)
+    json (1.8.2)
+    kramdown (1.5.0)
+    liquid (2.6.1)
+    listen (2.8.5)
+      celluloid (>= 0.15.2)
       rb-fsevent (>= 0.9.3)
       rb-inotify (>= 0.9)
-      rb-kqueue (>= 0.2)
     maruku (0.7.0)
+    mercenary (0.3.5)
+    mini_portile (0.6.2)
+    minitest (5.5.1)
+    net-dns (0.8.0)
+    nokogiri (1.6.5)
+      mini_portile (~> 0.6.0)
     parslet (1.5.0)
       blankslate (~> 2.0)
-    posix-spawn (0.3.8)
-    pygments.rb (0.5.4)
+    posix-spawn (0.3.9)
+    public_suffix (1.4.6)
+    pygments.rb (0.6.0)
       posix-spawn (~> 0.3.6)
       yajl-ruby (~> 1.1.0)
     rb-fsevent (0.9.4)
-    rb-inotify (0.9.3)
-      ffi (>= 0.5.0)
-    rb-kqueue (0.2.0)
+    rb-inotify (0.9.5)
       ffi (>= 0.5.0)
     rdiscount (2.1.7)
-    redcarpet (2.3.0)
-    safe_yaml (0.9.7)
-    toml (0.1.0)
+    redcarpet (3.1.2)
+    safe_yaml (1.0.4)
+    sass (3.4.10)
+    terminal-table (1.4.5)
+    thread_safe (0.3.4)
+    timers (4.0.1)
+      hitimes
+    toml (0.1.2)
       parslet (~> 1.5.0)
-    unindent (1.0)
+    tzinfo (1.2.2)
+      thread_safe (~> 0.1)
     yajl-ruby (1.1.0)
 
 PLATFORMS
   ruby
 
 DEPENDENCIES
-  github-pages!
-  jekyll
-  unindent
+  github-pages

documentation/advanced-features/capistrano-pure-ruby/index.markdown

@@ -2,7 +2,10 @@
 title: Capistrano in ruby script
 layout: default
 ---
-Instead of building a config folder and deploy, you may want to programmatically set everything in a single ruby script. This could be done as follows:
+
+Instead of building a config folder and deploy, you may want to
+programmatically set everything in a single ruby script. This could be done as
+follows:
 
 {% highlight ruby %}
 require 'capistrano/all'
@@ -22,4 +25,5 @@ Instead of building a config folder and deploy, you may want to programmatically
 Capistrano::Application.invoke("deploy")
 {% endhighlight%}
 
-Note that the require order is important as the stage needs to be set before you load setup and deploy.
+Note that the require order is important as the stage needs to be set before
+you load setup and deploy.

documentation/advanced-features/overriding-capistrano-tasks/index.markdown

@@ -3,7 +3,9 @@ title: Overriding Capistrano tasks
 layout: default
 ---
 
-When re-defining a task in Capistrano v2, the original task was replaced. The Rake DSL on which Capistrano v3 is built is additive however, which means that given the following definitions
+When re-defining a task in Capistrano v2, the original task was replaced. The
+Rake DSL on which Capistrano v3 is built is additive however, which means that
+given the following definitions
 
 {% highlight ruby %}
 task :foo do
@@ -17,13 +19,18 @@ end
 
 Will print both `foo` and `bar`.
 
-But it is also possible to completely clear a task and then re-defining it from scratch. A `Rake::Task` provides the `clear` method for this, which internally performs three separate actions:
+But it is also possible to completely clear a task and then re-defining it
+from scratch. A `Rake::Task` provides the `clear` method for this, which
+internally performs three separate actions:
 
 - `clear_prerequisites`
 - `clear_actions`
 - `clear_comments`
 
-Clearing the prerequisites (i.e. any dependencies that may have been defined for a task) is probably not what you want, though. Let's say, for example, that you want to re-define the `deploy:revert_release` task, which is defined as follows:
+Clearing the prerequisites (i.e. any dependencies that may have been defined
+for a task) is probably not what you want, though. Let's say, for example,
+that you want to re-define the `deploy:revert_release` task, which is defined
+as follows:
 
 {% highlight ruby %}
 task :revert_release => :rollback_release_path do
@@ -31,9 +38,12 @@ task :revert_release => :rollback_release_path do
 end
 {% endhighlight %}
 
-Calling `clear` on this task and then re-defining it results in `rollback_release_path` never being called, thus breaking rollback behavior.
+Calling `clear` on this task and then re-defining it results in
+`rollback_release_path` never being called, thus breaking rollback behavior.
 
-Under most circumstances, you will simply want to use `clear_actions`, which removes the specified task's behaviour, but does not alter it's dependencies or comments:
+Under most circumstances, you will simply want to use `clear_actions`, which
+removes the specified task's behaviour, but does not alter it's dependencies
+or comments:
 
 {% highlight ruby %}
 task :init do

documentation/advanced-features/ptys/index.markdown

@@ -3,21 +3,25 @@ title: PTYs
 layout: default
 ---
 
-There is a configuration option which asks the backend driver to ask the remote host
-to assign the connection a *pty*. A *pty* is a pseudo-terminal, which in effect means
-*tell the backend that this is an __interactive__ session*. This is normally a bad idea.
+There is a configuration option which asks the backend driver to ask the
+remote host to assign the connection a *pty*. A *pty* is a pseudo-terminal,
+which in effect means *tell the backend that this is an __interactive__
+session*. This is normally a bad idea.
 
-Most of the differences are best explained by [this page](https://github.com/sstephenson/rbenv/wiki/Unix-shell-initialization) from the author of *rbenv*.
+Most of the differences are best explained by [this
+page](https://github.com/sstephenson/rbenv/wiki/Unix-shell-initialization)
+from the author of *rbenv*.
 
-**When Capistrano makes a connection it is a *non-login*, *non-interactive* shell.
-This was not an accident!**
+**When Capistrano makes a connection it is a *non-login*, *non-interactive*
+shell. This was not an accident!**
 
-It's often used as a band aid to cure issues related to RVM and rbenv not loading login
-and shell initialisation scripts. In these scenarios RVM and rbenv are the tools at fault,
-or at least they are being used incorrectly.
+It's often used as a band aid to cure issues related to RVM and rbenv not
+loading login and shell initialisation scripts. In these scenarios RVM and
+rbenv are the tools at fault, or at least they are being used incorrectly.
 
-Whilst, especially in the case of language runtimes (Ruby, Node, Python and friends in
-particular) there is a temptation to run multiple versions in parallel on a single server
-and to switch between them using environmental variables, this is an anti-pattern, and
-symptomatic of bad design (e.g. you're testing a second version of Ruby in production because
-your company lacks the infrastructure to test this in a staging environment).
+Whilst, especially in the case of language runtimes (Ruby, Node, Python and
+friends in particular) there is a temptation to run multiple versions in
+parallel on a single server and to switch between them using environmental
+variables, this is an anti-pattern, and symptomatic of bad design (e.g. you're
+testing a second version of Ruby in production because your company lacks the
+infrastructure to test this in a staging environment).

documentation/advanced-features/remote-file/index.markdown

@@ -20,5 +20,4 @@ before running the check:linked_files task:
 file '/tmp/newrelic.yml' do |t|
   sh "curl -o #{t.name} https://rpm.newrelic.com/accounts/xx/newrelic.yml"
 end
-
 {% endhighlight %}

documentation/faq/why-does-something-work-in-my-ssh-session-but-not-in-capistrano/index.markdown

@@ -87,7 +87,7 @@ can have a very simple, Capfile, we don't even need to load the default
 recipes to test this:
 
 {% highlight ruby %}
-    # Capistrano 3.0.x
+# Capistrano 3
 task :query_interactive do
   on 'me@remote' do
     info capture("[[ $- == *i* ]] && echo 'Interactive' || echo 'Not interactive'")

documentation/getting-started/authentication-and-authorisation/index.markdown

@@ -3,11 +3,12 @@ title: Authentication & Authorisation
 layout: default
 ---
 
-**Note:** In the documentation we simply recommend creating a single deployment user,
-and sharing it between team members. If you know why this is a bad idea (or
-why this may be against regulations in your jurisdiction in some cases, we
-assume that you know well enough how to use groups, umasking and setgid bits
-to make this work reliably for unique logins across team members)
+**Note:** In the documentation we simply recommend creating a single
+deployment user, and sharing it between team members. If you know why this is
+a bad idea (or why this may be against regulations in your jurisdiction in
+some cases, we assume that you know well enough how to use groups, umasking
+and setgid bits to make this work reliably for unique logins across team
+members)
 
 To create this deploy user we'll assume something like the following has been
 done:

documentation/getting-started/flow/index.markdown

@@ -40,7 +40,8 @@ deploy:finishing_rollback  - finish the rollback, clean up everything
 deploy:finished
 {% endhighlight %}
 
-As you can see, rollback flow shares many tasks with deploy flow. But note that, rollback flow runs its own `:finishing_rollback` task because its
+As you can see, rollback flow shares many tasks with deploy flow. But note
+that, rollback flow runs  its own `:finishing_rollback` task because its
 cleanup process is usually different from deploy flow.
 
 ### Flow examples
@@ -108,4 +109,3 @@ deploy
   deploy:finished
     deploy:log_revision
 {% endhighlight %}
-

documentation/getting-started/installation/index.markdown

@@ -3,7 +3,7 @@ title: Installation
 layout: default
 ---
 
-Capistrano is bundled as a Ruby Gem. **It requires Ruby 1.9 or newer.**
+Capistrano is bundled as a Ruby Gem. **It requires Ruby 1.9.3 or newer.**
 
 Capistrano can be installed as a standalone Gem, or bundled into your
 application.

documentation/getting-started/preparing-your-application/index.markdown

@@ -133,8 +133,10 @@ These host strings are parsed and expanded out in to the equivalent of the
 server line after the comment:
 
 {% highlight ruby %}
+# using simple syntax
 role :web, %w{hello@world.com example.com:1234}
-  # ...is the same as doing...
+
+# using extended syntax (which is equivalent)
 server 'world.com', roles: [:web], user: 'hello'
 server 'example.com', roles: [:web], port: 1234
 {% endhighlight %}

documentation/getting-started/structure/index.markdown

@@ -30,11 +30,27 @@ Then inspecting the directories inside `/var/www/my_app_name` looks like this:
 {% endhighlight %}
 
 
-  * `current` is a symlink pointing to the latest release. This symlink is updated at the end of a successful deployment. If the deployment fails in any step the `current` symlink still points to the old release.
-  * `releases` holds all deployments in a timestamped folder. These folders are the target of the `current` symlink.
-  * `repo` holds the version control system configured. In case of a git repository the content will be a raw git repository (e.g. objects, refs, etc.).
-  * `revisions.log` is used to log every deploy or rollback. Each entry is timestamped and the executing user (username from local machine) is listed. Depending on your VCS data like branchnames or revision numbers are listed as well.
-  * `shared` contains the `linked_files` and `linked_dirs` which are symlinked into each release. This data persists across deployments and releases. It should be used for things like database configuration files and static and persistent user storage handed over from one release to the next.
+* `current` is a symlink pointing to the latest release. This symlink is
+updated at the end of a  successful deployment. If the deployment fails in any
+step the `current` symlink still points to the  old release.
 
+* `releases` holds all deployments in a timestamped folder. These folders are
+the target of the `current` symlink.
 
-The application is completely contained within the path of `:deploy_to`. If you plan on deploying multiple applications to the same server, simply choose a different `:deploy_to` path.
+* `repo` holds the version control system configured. In case of a git
+repository the content will be a  raw git repository (e.g. objects, refs,
+etc.).
+
+* `revisions.log` is used to log every deploy or rollback. Each entry is
+timestamped and the executing  user (username from local machine) is listed.
+Depending on your VCS data like branchnames or revision  numbers are listed as
+well.
+
+* `shared` contains the `linked_files` and `linked_dirs` which are symlinked
+into each release. This  data persists across deployments and releases. It
+should be used for things like database configuration  files and static and
+persistent user storage handed over from one release to the next.
+
+The application is completely contained within the path of `:deploy_to`. If
+you plan on deploying multiple applications to the same server, simply choose
+a different `:deploy_to` path.

documentation/overview/introductory-demo-video/index.markdown

@@ -1,36 +0,0 @@
----
-title: Introductory Demo Video
-layout: default
----
-
-The video below was filmed on Mac OSX 10.8 using a more-or-less standard shell
-without much previous setup.
-
-It covers using Capistrano to install an example Rails project on a previously
-unprepared server, covering all aspects of Github access, as well as
-privisioning the server using *Chef Solo* and Capistrano with *Rake*.
-
-#### Show Notes
-
-The *Chef Solo* recipes can be reached at [this repository at
-Github][capistrano-chef-solo-example-recipes], they rely on a fairly new
-version of *Chef Solo*, spefically any including the results of [this
-ticket][chef-issue-3365]. The aforementioned *Chef* issue adds environment
-support to *Chef Solo*.
-
-The provisioning can also be done using any other mechanism, it's generally
-accepted however that there's not much point in automising your deploys,
-unless you are also automating provisioning of your servers for a known,
-consistent state.
-
-Using `sudo` with any deployment can be tricky, so it's better to avoid it.
-Rebooting services without `sudo` is typically the first place people run into
-trouble using Capistrano. The [trouble shooting page for `sudo`
-problems][troubleshooting-sudo-password] may help.
-
-**Note:** Some long sequences have been shortened (nobody needs to sit and watch me
-sitting and watching Ruby compile, for example!)
-
---
-[chef-issue-3365]: https://github.com/opscode/chef/pull/359
-[troubleshooting-sudo-password]: /troubleshooting/sudo-password/

documentation/overview/what-is-capistrano/index.markdown

@@ -142,6 +142,5 @@ There's lots of cool stuff in the Capistrano toy box:
       info "Phew, it's ok, the directory exists!"
     end
   end
-
 end
 {% endhighlight %}

documentation/upgrading/index.markdown

@@ -63,7 +63,6 @@ layout: default
 
 *Important: `repository` option was renamed to `repo_url`; `default_environment` option was renamed to `default_env`.*
 
-
 Notice that some parameters are not necessary anymore: `use_sudo`, `normalize_asset_timestamps`.
 
 7.