Permalink
Browse files

Removing references to the testing mode. It was just confusing users.

When the time comes, will add it back.
  • Loading branch information...
1 parent 8972afd commit da96fa15a7a7c16eef5ec426e04817d41d9d9887 @gerhard committed Jul 18, 2012
Showing with 22 additions and 154 deletions.
  1. +1 −1 README.md
  2. +2 −3 bin/deliver
  3. +16 −19 libexec/core
  4. +0 −16 libexec/init
  5. +1 −12 man/deliver.1
  6. +1 −52 man/deliver.1.html
  7. +1 −51 man/deliver.ronn
View
@@ -1,7 +1,7 @@
Deliver is a pure bash deployment tool with virtually no dependencies.
It only cares about having enough info in the shell environment to do
its job. Why add Ruby or Python wrappers on top of system commands when
-bash was built for this one task?
+bash was built for this?
Capistrano was just infuriating when you added rvm and bundler into the
mix, git-deploy is great for single server, but what if you're running a
View
@@ -40,10 +40,9 @@ __check_config
# Run the loaded strategy
# Can be overwritten by each strategy, e.g. custom output
-# When testing, only output the commands which would be run
#
-[ ! $MODE = "test" ] && begin
+begin
run
-[ ! $MODE = "test" ] && finish
+finish
exit 0 # if we reached this point, everything went according to plan, use the appropriate exit status
View
@@ -258,25 +258,22 @@ __remote() {
#__parallelize "ssh -o ConnectTimeout=$SSH_TIMEOUT \"\$_host\" \"$_remote_job\""
- if [[ $MODE != "test" ]]
- then
- local _remote_job="$1"
- local _hosts="${2:-"$SERVERS_APP_USER"}"
- background_jobs_pids=()
- background_jobs=()
-
- __log "${_hosts} : $_remote_job"
-
- for _host in $_hosts
- do
- ssh -o ConnectTimeout="$SSH_TIMEOUT" "$_host" "$_remote_job $SILENCE" &
- background_jobs_pids+=("$!")
- local _background_job="ssh -o ConnectTimeout=$SSH_TIMEOUT $_host $_remote_job $SILENCE"
- background_jobs+=("$_background_job")
- done
-
- __monitor_background_jobs
- fi
+ local _remote_job="$1"
+ local _hosts="${2:-"$SERVERS_APP_USER"}"
+ background_jobs_pids=()
+ background_jobs=()
+
+ __log "${_hosts} : $_remote_job"
+
+ for _host in $_hosts
+ do
+ ssh -o ConnectTimeout="$SSH_TIMEOUT" "$_host" "$_remote_job $SILENCE" &
+ background_jobs_pids+=("$!")
+ local _background_job="ssh -o ConnectTimeout=$SSH_TIMEOUT $_host $_remote_job $SILENCE"
+ background_jobs+=("$_background_job")
+ done
+
+ __monitor_background_jobs
}
# Logs all events (including formatting styles) so that people can tail,
View
@@ -20,7 +20,6 @@ ${txtbld}Modes:${txtrst}
-C, --compact Displays every task as it's run, silences all output. (default mode)
-V, --verbose Same as above, does not silence output.
-D, --debug Runs in shell debug mode, displays everything.
- -T, --testing Similar to a dry-run. Displays the generated bash code.
${txtbld}Options:${txtrst}
-s, --strategy Enforces a particular strategy.
@@ -60,9 +59,6 @@ do
(-V|--verbose)
MODE="verbose"
;;
- (-T|--test)
- MODE="test"
- ;;
(-h|--help)
__help
exit 0
@@ -101,16 +97,4 @@ case "${MODE}" in
VERBOSE=true
SILENCE=""
;;
- (test)
- TEST=true
- ;;
esac
-
-# Print functions in test mode
-#
-#(test)
- ##printf '%q' $(declare -f $1)
- #IFS='%'
- #echo -e $(declare -f "$1")
- #unset IFS
-#;;
View
@@ -18,7 +18,7 @@
.br
.
.SH "DESCRIPTION"
-Deliver is a pure bash deployment tool with virtually no dependencies\. It only cares about having enough info in the shell environment to do its job\. Why add Ruby or Python wrappers on top of system commands when bash was built for this one task?
+Deliver is a pure bash deployment tool with virtually no dependencies\. It only cares about having enough info in the shell environment to do its job\. Why add Ruby or Python wrappers on top of system commands when bash was built for this?
.
.SH "STRATEGIES"
\fBdeliver strategies\fR will list all available strategies\. The default strategies make certain assumptions, but they are fully modular and customizable\.
@@ -35,10 +35,6 @@ Heavily inspired by the ruby strategy, also foreman\-aware, defaults to upstart\
\fBgh\-pages\fR
How many times did you find yourself copying that rake task which generates and publishes to github:pages \fIhttp://pages\.github\.com/\fR your project\'s docco \fIhttps://github\.com/jashkenas/docco\fR or rocco \fIhttps://github\.com/rtomayko/rocco\fR? With deliver, just run \fBdeliver \-s gh\-pages\fR from the app\'s root path\.
.
-.SS "Customizing a default strategy?"
-.
-.SS "Creating a new strategy?"
-.
.SH "CHECK"
\fBdeliver check\fR will ensure that everything is set up correctly\. You can also use this to see your final configuration\.
.
@@ -60,12 +56,5 @@ Will not silence output of the running task\. Great for troubleshooting or getti
\fB\-D\fR, \fB\-\-debug\fR (or \fBMODE=debug\fR)
Runs the entire script in standard shell debug mode, shows every line of bash that gets executed along with the task output\. Well suited when writing your own strategies or customizing existing ones\.
.
-.TP
-\fB\-T\fR, \fB\-\-test\fR (or \fBMODE=test\fR)
-Similar to a dry\-run\. Will output each command that is going to run with no local or remote changes\. If you want full visibility into the final system commands that get generated, use this mode\.
-.
-.IP
-If you want tighter control over your deployment process, you can have everyone on the team using the generated commands rather than using deliver directly\.
-.
.SH "COPYRIGHT"
Deliver is Copyright (C) 2012 Gerhard Lazu \fIhttp://twitter\.com/gerhardlazu\fR
View
@@ -89,8 +89,7 @@ <h2 id="DESCRIPTION">DESCRIPTION</h2>
<p>Deliver is a pure bash deployment tool with virtually no dependencies. It only
cares about having enough info in the shell environment to do its job. Why add
-Ruby or Python wrappers on top of system commands when bash was built for this
-one task?</p>
+Ruby or Python wrappers on top of system commands when bash was built for this?</p>
<h2 id="STRATEGIES">STRATEGIES</h2>
@@ -108,10 +107,6 @@ <h2 id="STRATEGIES">STRATEGIES</h2>
</dl>
-<h3 id="Customizing-a-default-strategy-">Customizing a default strategy?</h3>
-
-<h3 id="Creating-a-new-strategy-">Creating a new strategy?</h3>
-
<h2 id="CHECK">CHECK</h2>
<p><code>deliver check</code> will ensure that everything is set up correctly. You can also
@@ -135,59 +130,13 @@ <h2 id="RUNNING-MODES">RUNNING MODES</h2>
<dt><code>-D</code>, <code>--debug</code> (or <code>MODE=debug</code>)</dt><dd><p>Runs the entire script in standard shell debug mode, shows every line of
bash that gets executed along with the task output. Well suited when writing
your own strategies or customizing existing ones.</p></dd>
-<dt><code>-T</code>, <code>--test</code> (or <code>MODE=test</code>)</dt><dd><p>Similar to a dry-run. Will output each command that is going to run with no
-local or remote changes. If you want full visibility into the final system
-commands that get generated, use this mode.</p>
-
-<p>If you want tighter control over your deployment process, you can have
-everyone on the team using the generated commands rather than using deliver
-directly.</p></dd>
</dl>
<h2 id="COPYRIGHT">COPYRIGHT</h2>
<p>Deliver is Copyright (C) 2012 <a href="http://twitter.com/gerhardlazu">Gerhard Lazu</a></p>
-<!--
-With no options, it will run in compact mode and will use the STRATEGY from
-your runtime env, shell env or .deliver/config file. If you don't define a
-strategy, it will use the ruby one by default.
-
-If your specify a runtime strategy, this overwrite any subsequent configs:
-
- STRATEGY=gh-pages deliver
-
-The above will use the gh-pages strategy, regardless of what you have
-defined in your .deliver/config file or your shell env.
-
-All settings respect the following priority (lower number takes precedence):
-
-1. Runtime env
-2. Shell env
-3. Deliver config file
-
-This becomes very helpful if you want to deploy your app to a local VM before
-pushing to production. You can invoke deliver with runtime envs without any
-modifications to your .deliver/config file:
-
- SERVER=ruby-1-localvm deliver
-
-You can also deliver to multiple servers:
-
- SERVER=ruby-1-local,ruby-2-local deliver
-
-When you're ready to update production, given that you already have the
-correct servers defined in your .deliver/config file, run deliver without any
-runtime variables.
-
-At any point, you can test your deliver setup to see if everything is
-configured correctly:
--->
-
-
-
-
<ol class='man-decor man-foot man foot'>
<li class='tl'>Deliver 0.5.0</li>
View
@@ -9,8 +9,7 @@ deliver(1) -- takes your code into production
## DESCRIPTION
Deliver is a pure bash deployment tool with virtually no dependencies. It only
cares about having enough info in the shell environment to do its job. Why add
-Ruby or Python wrappers on top of system commands when bash was built for this
-one task?
+Ruby or Python wrappers on top of system commands when bash was built for this?
## STRATEGIES
`deliver strategies` will list all available strategies. The default strategies
@@ -29,10 +28,6 @@ make certain assumptions, but they are fully modular and customizable.
and publishes to [github:pages][3] your project's [docco][4] or [rocco][5]?
With deliver, just run `deliver -s gh-pages` from the app's root path.
-### Customizing a default strategy?
-
-### Creating a new strategy?
-
## CHECK
`deliver check` will ensure that everything is set up correctly. You can also
use this to see your final configuration.
@@ -59,15 +54,6 @@ be *verbose*.
bash that gets executed along with the task output. Well suited when writing
your own strategies or customizing existing ones.
- * `-T`, `--test` (or `MODE=test`):
- Similar to a dry-run. Will output each command that is going to run with no
- local or remote changes. If you want full visibility into the final system
- commands that get generated, use this mode.
-
- If you want tighter control over your deployment process, you can have
- everyone on the team using the generated commands rather than using deliver
- directly.
-
## COPYRIGHT
Deliver is Copyright (C) 2012 [Gerhard Lazu][6]
@@ -77,39 +63,3 @@ Deliver is Copyright (C) 2012 [Gerhard Lazu][6]
[4]: https://github.com/jashkenas/docco
[5]: https://github.com/rtomayko/rocco
[6]: http://twitter.com/gerhardlazu
-
-<!--
-With no options, it will run in compact mode and will use the STRATEGY from
-your runtime env, shell env or .deliver/config file. If you don't define a
-strategy, it will use the ruby one by default.
-
-If your specify a runtime strategy, this overwrite any subsequent configs:
-
- STRATEGY=gh-pages deliver
-
-The above will use the gh-pages strategy, regardless of what you have
-defined in your .deliver/config file or your shell env.
-
-All settings respect the following priority (lower number takes precedence):
-
-1. Runtime env
-2. Shell env
-3. Deliver config file
-
-This becomes very helpful if you want to deploy your app to a local VM before
-pushing to production. You can invoke deliver with runtime envs without any
-modifications to your .deliver/config file:
-
- SERVER=ruby-1-localvm deliver
-
-You can also deliver to multiple servers:
-
- SERVER=ruby-1-local,ruby-2-local deliver
-
-When you're ready to update production, given that you already have the
-correct servers defined in your .deliver/config file, run deliver without any
-runtime variables.
-
-At any point, you can test your deliver setup to see if everything is
-configured correctly:
--->

0 comments on commit da96fa1

Please sign in to comment.