Formats files

lib/bootleg/tasks/build/remote.exs

@@ -313,26 +313,25 @@ end
 
 task :clean_for_upgrade do
   remote :build do
-      "ls"
-    end
-  |> Enum.map( fn result ->
-      with {:ok, stdout_list, _code, _host} when stdout_list != [] <- result do
-
-            locations =
-              stdout_list
-              |> Keyword.get(:stdout)
-              |> String.split("\n")
-              |> Enum.drop(-1)
-              |> Enum.filter(fn el -> el != "_build" end)
-              |> Enum.join(" ")
-
-            if locations != "" do
-               remote :build do
-                 "rm -rvf #{locations}"
-               end
-            end
+    "ls"
+  end
+  |> Enum.map(fn result ->
+    with {:ok, stdout_list, _code, _host} when stdout_list != [] <- result do
+      locations =
+        stdout_list
+        |> Keyword.get(:stdout)
+        |> String.split("\n")
+        |> Enum.drop(-1)
+        |> Enum.filter(fn el -> el != "_build" end)
+        |> Enum.join(" ")
+
+      if locations != "" do
+        remote :build do
+          "rm -rvf #{locations}"
+        end
       end
-    end)
+    end
+  end)
 end
 
 task :generate_upgrade_release do
@@ -359,7 +358,7 @@ task :remote_hot_upgrade do
   app_name = "#{Config.app()}"
 
   UI.info("Upgrading #{app_name} to version: #{Config.version()}")
-  
+
   remote :app do
     "bin/#{app_name} upgrade #{Config.version()}"
   end

lib/bootleg/tasks/deploy_upgrade.exs

@@ -48,5 +48,3 @@ task :unpack_release_upgrade do
 
   UI.info("Unpacked release upgrade archive")
 end
-
-

lib/mix/tasks/upgrade.ex

@@ -26,7 +26,7 @@ defmodule Mix.Tasks.Bootleg.Upgrade do
   the code of a running application without the need to 
   stopping and restarting it, i.e. mantaining active the 
   service in production.
-  
+
   This is one of the most interesting capabilities of Erlang/OTP,
   but it is a very complex process that *cannot* be fully 
   automated, i.e. require a good knowledge of the tecnologies 
@@ -60,24 +60,24 @@ defmodule Mix.Tasks.Bootleg.Upgrade do
     https://hexdocs.pm/distillery/guides/appups.html
 
   ### Bootleg hot upgrade task
-  
+
   In the following description we assume that the development 
   enviroinment is organized in this way (the build and 
   the production places can be the same machine):
-  
+
     * the development machine - where you edit and 
       test locally your app source files;
-  
+
     * the build machine - the computer where you will transfer to
       and compile the committed source code;
-  
+
     * the production server - the server where you will deploy 
       (transfer to and run) the code previously compiled on 
       the build machine.
-  
+
   Bootleg helps you in the hot upgrade process providing 
   some specific tasks:
-  
+
     * mix bootleg.build_upgrade
       will tranfer the last committed source code of your application
       from the development machine to the build directory of 
@@ -89,76 +89,76 @@ defmodule Mix.Tasks.Bootleg.Upgrade do
       you have to deploy your _first version_ of your app using 
       `bootleg.build`, `bootleg.deploy` and `bootleg.start` 
       (or `bootleg.update`);
-  
+
     * mix bootleg.deploy_upgrade
       will transfer the tarball of the compiled app from the 
       build machine to the production directory of the production
       machine, e.g. `~/production/myapp/`
-  
+
       then will extract and setting up the needed files;
-  
+
     * mix bootleg.hot_upgrade
       will call `mix distillery <myapp> upgrade <version>` that
       will upgrade the running app to the last version. Notice that
       you *cannot* use this task if the app is not running, or 
       if it there is a mismatch in the version numbers of the
       deployed versions.
-  
+
     * mix bootleg.upgrade
       Call in sequences the above tasks in just one command.
-  
+
   ### A step-by-step example
-  
+
   Given you have configured the first version of your app with all
   the needed and appropriately customized Bootleg configuration files, 
   you can go through the following steps to release and run the 
   first version and subsequentely hot upgrade it to the newest
   versions:
-  
+
   First version of your app:
-  
+
     # Step 1 - deploy the first version of your app
       edit the version number of your in the mix.exs file 
       (or in the file if you use an external reference),
       to the first version, e.g. 0.1.0;
-  
+
     # Step 2 - Commit
       commit the changes you've made in step 1;
-  
+
     # Step 3 - Build the first version
       use `mix bootleg.build` (not bootleg.build_upgrade!) to build 
       your first version;
-  
+
     # Step 4 - Deploy the first version
       use `mix bootleg.deploy` (not bootleg.build_upgrade!) to deploy 
       your first version;
-  
+
     # Step 5 - Run the first version
       use `mix bootleg.start` to run the app
-  
+
     now your first version is up and running. To upgrade it 
     to the future version, you have to follow these steps instead.
-  
+
   Following versions:
-  
+
     # Step 1 - update the version number
       e.g. 0.2.0
-  
+
     # Step 2 - Commit
-  
+
     # Step 3 - Build the new version
       use `mix bootleg.build_upgrade`
-  
+
     # Step 4 - Deploy the new version
       use `mix bootleg.deploy_upgrade`
-  
+
     # Step 5 - Hot upgrade the new version
       use `mix bootleg.hot_upgrade`
-  
+
     (or you can execute just the `bootleg.upgrade` 
     that packs the previous tasks together if you don't need to
     manually adjust the created `appup` file)
-  
+
     Now you have an upgraded version running. But if you stop
     and restart it, the previous version will be launched instead
     of the most recent. This is useful because if your new version