fulmar 1.10.1 → 2.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: c6e4cd1b4895e08c5b2548ea7680e13071e5a1d7
-  data.tar.gz: 3f141c76b47aab32bd21a40a4629d79df2c92c95
+  metadata.gz: e8d6270f2a2b407f32d9419cd4bb55c228138b8e
+  data.tar.gz: 2c820de490c174e1c7a0df5db92434fe1a3f3302
 SHA512:
-  metadata.gz: d1bedf9ff9ee0780bfe6056dc9b295d43aa4d13d32f114e052090e059860c1abb394088efc9d4a7ac1c9fc617b5db3ca885c72e513d3e827774d35575fe901b5
-  data.tar.gz: 8ea30f40735b20aa8b0d18256c6c1467d8060fc5d0227f756b21dd75545d8e00128c69c135f83a22376530b146dbe9b927e92d720672b9834488aad0c38a8bb8
+  metadata.gz: 308c77aa59ef61e622a7988c5bbafb86b76694408d5d6b112e311813a9175c34260aff4954449f358e3722de481ff3570ac79c3e21d6c3ef904be72fbab9ada9
+  data.tar.gz: ae114e84ce4907f2feefe402f1409cbbfe76497c3e47dc15dbe676964df877150bf22f14dd7c763963fe4be954e9997e571c32979a7457c7d067a0ceb7255966

data/.gitignore

@@ -14,7 +14,7 @@
 mkmf.log
 /.idea/
 *.gem
-/Vagrantfile
 /.vagrant
+/Vagrantfile
 /vendor
 /test/deployment

data/.travis.yml

@@ -1,11 +1,18 @@
 language: ruby
 rvm:
-  - 2.0
-  - 2.1
-  - 2.2
+  - 2.2.2
+  - 2.3.1
+  - 2.4.0
   - ruby-head
-before_install: gem install bundler -v 1.10.6
 matrix:
   fast_finish: true
   allow_failures:
     - rvm: ruby-head
+
+before_script:
+  - bundle update
+
+script:
+  - git config --global user.email "you@example.com"
+  - git config --global user.name "Whatever Name"
+  - bundle exec rspec spec

data/README.md

@@ -12,28 +12,12 @@ the cache and the publish via a symlink. This avoids an inconsistent state on th
 machine and allows a quick revert to the old version, as long as other dependencies are
 compatible (i.e. database).
 
-It has (yet limited) support for MySQL / MariaDB and git. Remote databases can be accessed
-through an ssh tunnel.
-
-## Warning
-
-Version 1.10.0 of Fulmar removes some features that we (CORE4) rarely used and which
-caused the deployments to slow down the gems needed to be compiled against the
-installed libraries. If you need support to query databases (more than just dumps)
-or use dependencies, you will need to explicitly specify version `~> 1.9.0`.
-Fulmar 2.0 will support these features via plugins.
+It has (yet limited) support for MySQL / MariaDB and git.
 
 ## Prerequisites
 
-Fulmar 1.9 currently requires the [mysql2](https://github.com/brianmario/mysql2) gem which
-requires the mysql header files. So on a linux system, you want to install
-libmariadbclient-dev/libmysqlclient-dev or similar.
-
-You also need cmake and pkg-config to build the dependencies.
-
-- OSX: brew install mariadb cmake pkg-config
-- Ubuntu: apt-get install libmariadb-client-lgpl-dev build-essential cmake
-- Ubuntu (pre-xenial): apt-get install libmariadbclient-dev build-essential cmake
+Fulmar 2.0 runs with Ruby >= 2.2.2. Plugins like [mariadb](https://github.com/CORE4/fulmar-plugin-mariadb) might have
+additional requirements.
 
 ## Installation
 
@@ -57,20 +41,24 @@ Fulmar works like Rake. In fact it is just a collection of services on top of Ra
 
 ## A simple start
 
-Start by creating a file named "Fulmarfile" in your project root. Then add a Folder "Fulmar" with a project.config.yml in it. The name of the config file doesn't matter, it just needs to end with .config.yml. All \*.config.yml in the Fulmar directory are merged so you can split you configuration into
+Start by creating a file named "Fulmarfile" in your project root. Then add a Folder "Fulmar" with a project.config.yml
+in it. The name of the config file doesn't matter, it just needs to end with .config.yml. All \*.config.yml in the
+Fulmar directory are merged so you can split you configuration into
 several files.
 
     $ touch Fulmarfile
     $ mkdir Fulmar
     $ touch Fulmar/project.config.yml
 
-You can now test your configuration.
+You can now now test your configuration.
 
     $ fulmar test:config
 
-Everything should be fine. With `fulmar -T` you can get a quick overview on the available tasks. That is probably just one, the fulmar console. We'll come back to this later.
+Everything should be fine. With `fulmar -T` you can get a quick overview on the available tasks. That is probably just
+one, the fulmar console. We'll come back to this later.
 
-Now let's start with a first configuration. You might want to have a server ready which you can access via ssh and public key authentication. Add this to you configuration file (Fulmar/project.config.yml):
+Now let's start with a first configuration. You might want to have a server ready which you can access via ssh and
+public key authentication. Add this to you configuration file (Fulmar/project.config.yml):
 
 ```yaml
 environments:
@@ -85,15 +73,25 @@ environments:
         delete: false
 ```
 
-Now you can run a second test: `fulmar test:hosts`. This will test the ssh connection to your remote machine. You can add a username to the ssh configuration in the files section (below the hostname). However, if you need a finer grained host configuration, you should use your [ssh config file](http://www.cyberciti.biz/faq/create-ssh-config-file-on-linux-unix/).
+Now you can run a second test: `fulmar test:hosts`. This will test the ssh connection to your remote machine. You can
+add a username to the ssh configuration in the files section (below the hostname). However, if you need a finer
+grained host configuration, you should use your
+[ssh config file](http://www.cyberciti.biz/faq/create-ssh-config-file-on-linux-unix/).
 
-Most fulmar tasks need to run within a configured environment. Within the configuration, environments are split into targets. So actually, a task works within a target. In our example, we set up an environment named 'my_server' with a target named 'files'. You might want to use one environment for your development server, one for a preview server and one for the production machine. Within each environment you might have different hosts for the file and the database, so each environment can be split up into multiple targets (e.g. 'files' and 'database').
+Most fulmar tasks need to run within a configured environment. Within the configuration, environments are split into
+targets. So actually, a task works within a target. In our example, we set up an environment named 'my_server' with
+a target named 'files'. You might want to use one environment for your development server, one for a preview server
+and one for the production machine. Within each environment you might have different hosts for the file and the
+database, so each environment can be split up into multiple targets (e.g. 'files' and 'database').
 
-There is one special environment 'all' which contains settings you want to use in all targets of all environements. These globally configured settings are overwritten with the specific ones from a target if they exist. Useful examples for this are 'local_path' and 'debug'.
+There is one special environment 'all' which contains settings you want to use in all targets of all environements.
+These globally configured settings are overwritten with the specific ones from a target if they exist. Useful examples
+for this are 'local_path' and 'debug'.
 
 ### Tasks
 
-As you can see (`fulmar -T`), you cannot do anything more useful now. So it is time to write a first task. If you are familiar with rake, this should not be a problem.
+As you can see (`fulmar -T`), you cannot do anything more useful now. So it is time to write a first task. If you are
+familiar with rake, this should not be a problem.
 
 ```ruby
 namespace :deploy do
@@ -105,14 +103,17 @@ namespace :deploy do
 end
 ```
 
-This creates a task 'test' within the namespace 'deploy', which means you can access the task by running `fulmar deploy:test`. The task will load the configuration for 'myserver/files' and start a file sync (via rsync) to your remote host.
+This creates a task 'test' within the namespace 'deploy', which means you can access the task by running
+`fulmar deploy:test`. The task will load the configuration for 'myserver/files' and start a file sync (via rsync) to
+your remote host.
 
 If you log in to your remote machine, you should now see the Fulmar directory and the Fulmarfile in /tmp.
 ```bash
 ssh my-ssh-server "ls -l /tmp | grep Fulmar"
 ```
 
-This task can be even shorter. Fulmar creates some helper tasks automatically from your configuration. Just like in rake, you can list them via `fulmar -T -A`:
+This task can be even shorter. Fulmar creates some helper tasks automatically from your configuration. Just like in
+rake, you can list them via `fulmar -T -A`:
 ```
 fulmar console                      # Open an interactive terminal within fulmar
 fulmar deploy:test                  # Deploy to test system
@@ -122,7 +123,8 @@ fulmar test:config                  #
 fulmar test:hosts                   #
 ```
 
-Fulmar creates task for every environment/target with this scheme. So you can just set a dependency to these tasks to load the configuration. Your task now only needs one line:
+Fulmar creates task for every environment/target with this scheme. So you can just set a dependency to these tasks to
+load the configuration. Your task now only needs one line:
 
 ```ruby
 namespace :deploy do
@@ -139,11 +141,15 @@ task :test => ['environment:my_server:files', 'prepare_files', 'do_some_more'] d
 end
 ```
 
-If you call one task from another, your configuration will be given to the subtask. If you change the target in the subtask it will be reverted when returning to your main task unless you did not set any configuration in the main task. This means the following:
-- You can use the dependency to a 'environment:' task to set the target initially (as it will be the first subtask to run)
+If you call one task from another, your configuration will be given to the subtask. If you change the target in the
+subtask it will be reverted when returning to your main task unless you did not set any configuration in the main task.
+This means the following:
+- You can use the dependency to a 'environment:' task to set the target initially (as it will be the first subtask to
+  run)
 - You can call a subtask and and you don't have to worry it might change your target.
 
-*The configuration object is a singleton. So if you change the actual configuration of a target, it will affect other tasks*
+*The configuration object is a singleton. So if you change the actual configuration of a target, it will affect other
+tasks*
 
 ## Features
 
@@ -151,7 +157,8 @@ So now you can deploy the Fulmarfiles itself which is nice. So what else can you
 
 ### Shell
 
-Very often you need to call other programs or script from a shell to compile your assets or clear the cache. Within a task, you can access the local and remote shell:
+Very often you need to call other programs or script from a shell to compile your assets or clear the cache. Within a
+task, you can access the local and remote shell:
 
 ```ruby
 task :tutorial => 'environment:my_server:files' do
@@ -161,7 +168,8 @@ task :tutorial => 'environment:my_server:files' do
 end
 ```
 
-You can run multiple commands. If one fails, everything stops immediately. This is intended to stop the deployment of broken files.
+You can run multiple commands. If one fails, everything stops immediately. This is intended to stop the deployment of
+broken files.
 
 ```ruby
 task :tutorial => 'environment:my_server:files' do
@@ -188,7 +196,8 @@ end
 
 ### File synchronisation
 
-At the moment, there are two ways to synchronize your files to a remote host. The basic rsync and "rsync with versions". You already know how to set up the simple file sync. You can add a few options, if you like:
+At the moment, there are two ways to synchronize your files to a remote host. The basic rsync and "rsync with versions".
+You already know how to set up the simple file sync. You can add a few options, if you like:
 
 ```yaml
 environments:
@@ -210,16 +219,20 @@ environments:
 ```
 
 These are:
-- **delete**: true/false, Should additional files be deleted from the remote host? The default is "true", as you don't want to have legacy files opening security holes on your server.
+- **delete**: true/false, Should additional files be deleted from the remote host? The default is "true", as you don't
+want to have legacy files opening security holes on your server.
 - **exclude**: regexp, which works with "--exclude" from rsync. Usually, you should prefer the next option
-- **exclude_file**: Filename of the exclude file relative to "local_path". If you have a file called .rsyncignore in "local_path" this will be used automatically.
+- **exclude_file**: Filename of the exclude file relative to "local_path". If you have a file called .rsyncignore in
+"local_path" this will be used automatically.
 - **chown**: chown files on remote machine to this user
 - **chmod**: change mode of files on remote machines
-- **direction**: up/down, Should the files be uploaded or downloaded? The latter is useful if you want to download images created by a cms on the remote machine.
+- **direction**: up/down, Should the files be uploaded or downloaded? The latter is useful if you want to download
+images created by a cms on the remote machine.
 
 ### rsync with versions
 
-When deploying to a production machine, you want your minimize the downtime for the website. Fulmar can help by syncing different versions which are symlinked after they are set up.
+When deploying to a production machine, you want your minimize the downtime for the website. Fulmar can help by syncing
+different versions which are symlinked after they are set up.
 
 ```yaml
 environments:
@@ -238,13 +251,20 @@ environments:
       #shared_dir: shared
 ```
 
-You do no necessarily need to set "limit_releases" or "shared". "temp_dir", "releases_dir" and "shared_dir" are relative to the remote_path and usually do not need to be changed.
+You do no necessarily need to set "limit_releases" or "shared". "temp_dir", "releases_dir" and "shared_dir" are
+relative to the remote_path and usually do not need to be changed.
 
 So what does this all mean?
 
-If you still have your deploy:test task you can now deploy a first version of your files. Probably create the "data" dir first and put a file in to see what happens. Fulmar will sync you project into a temporary directory ("temp_dir") and then copy it the the releases directory with the current timestamp as a directory name. So in this case, a directory like "/tmp/releases/2015-04-27_123456" will be created. Fulmar will then look of shared/data exists and if not, copy it from the releases directory. Shared directories in releases will be deleted an symlinked to shared. So you want to list all directories which are filled by you web application (images uploaded from the cms, etc).
+If you still have your deploy:test task you can now deploy a first version of your files. Probably create the "data"
+dir first and put a file in to see what happens. Fulmar will sync you project into a temporary directory ("temp_dir")
+and then copy it the the releases directory with the current timestamp as a directory name. So in this case, a directory
+ like "/tmp/releases/2015-04-27_123456" will be created. Fulmar will then look of shared/data exists and if not, copy it
+  from the releases directory. Shared directories in releases will be deleted an symlinked to shared. So you want to
+  list all directories which are filled by you web application (images uploaded from the cms, etc).
 
-Then you can build up the cache or whatever needs to be done within that directory before putting it live. This last step is not yet covered in our little deployment task. So:
+Then you can build up the cache or whatever needs to be done within that directory before putting it live. This last
+step is not yet covered in our little deployment task. So:
 
 ```ruby
 namespace :deploy do
@@ -260,75 +280,26 @@ namespace :deploy do
 end
 ```
 
-The transfer() method of the file_sync service returns the created release dir and you can do what needs to be done before calling file_sync.publish to create the symlink (current => releases/2015-04-27_123456).
-
-As you probably figured out, your webserver uses the "current" symlink to get the base directory of your web application. Here, you would point it to /tmp/current/public or something like that.
-
-### Database access
-
-Within a task you can access and update databases (mariadb/mysql at the time of writing). Remote databases do not need to be accessible directly since fulmar uses an ssh tunnel to connect to the host first. So the database host is often just "localhost" (the default value). You can specify a different host if you database server is on another host, which is the case on most simple web spaces.
-
-The field "maria:database" is required for type "maria". The other fields are optional, though you probably need the fields "user" and "password". Below you can see the default values for the optional fields.
-
-```yaml
-environments:
-  staging:
-    database:
-      host: project-staging
-      type: maria
-      maria:
-        database: db_name
-        user: root
-        password:
-        port: 3306
-        host: localhost
-        encoding: utf-8
-```
-
-```ruby
-require 'pp'
-
-task :database => 'environment:staging:database' do
-  database.create 'test_db'
-  database.clear # deletes all tables within the database
-  remote_file_name = database.dump # dumps the database to the returned file
-  database.load_dump(remote_file_name) # loads an sql dump
-  local_filename = database.download_dump # downloads an sql dump to your machine
-end
-```
+The transfer() method of the file_sync service returns the created release dir and you can do what needs to be done
+before calling file_sync.publish to create the symlink (current => releases/2015-04-27_123456).
 
-You can query the database like this:
-
-```ruby
-results = database.query 'SELECT name, email FROM users'
-results.each do |row|
-  puts "#{row['name']} <#{row['email']}>"
-end
-```
-
-You can use all features of the mysql2 gem via `database.client`.
-
-If you configured more than one database on different environments, fulmar will
-create task to sync these databases via mysql_dump. This allows you to update a
-staging or preview database with the data from the production system.
-
-```
-fulmar database:update:preview:from_live
-```
-
-The task to copy data *to* the live database is hidden (it has no description).
+As you probably figured out, your webserver uses the "current" symlink to get the base directory of your web
+application. Here, you would point it to /tmp/current/public or something like that.
 
 ### Configuration templates
 
-Sometimes you need different versions of files on your different environments. An exmaple might be the .htaccess file. You can use the [Ruby ERB templating engine](http://www.stuartellis.eu/articles/erb/) to generate the different versions. The configuration of your environment are available via the `@config` variable.
+Sometimes you need different versions of files on your different environments. An exmaple might be the .htaccess file.
+You can use the [Ruby ERB templating engine](http://www.stuartellis.eu/articles/erb/) to generate the different
+versions. The configuration of your environment are available via the `@config` variable.
 
-Templates need to be named with the schema `<original_filename>.erb`. All files you want to render need to be listed in the configuration:
+Templates need to be named with the schema `<original_filename>.erb`. All files you want to render need to be listed in
+the configuration:
 
 ```yaml
 environments:
   staging:
     files:
-      config_templates:
+      templates:
         - .htaccess.erb
       application_environment: Production/Live
 ```
@@ -338,3 +309,17 @@ Then add the variable to your template:
 ```
 SetEnv APPLICATION_ENVIRONMENT "<%= @config['application_environment'] %>"
 ```
+
+## Plugins
+
+Fulmar can be extended with plugins.
+
+```yaml
+plugins:
+  mariadb:
+    # Put mariadb plugin configuration here
+  git:
+    # Put git plugin configuration here 
+```
+
+If you want to add your own plugin, have a look at the [example plugin](https://github.com/CORE4/fulmar-plugin-example).

data/fulmar.gemspec

@@ -20,8 +20,8 @@ Gem::Specification.new do |spec|
 
   spec.add_development_dependency 'bundler', '~> 1.7'
 
-  spec.add_runtime_dependency 'rake', '~>10'
+  spec.add_runtime_dependency 'rake', '~>11'
   spec.add_runtime_dependency 'fulmar-shell', '~>1', '>=1.7.0'
-  spec.add_runtime_dependency 'ruby_wings', '~>0.1', '>=0.1.1'
   spec.add_runtime_dependency 'colorize', '~>0'
+  spec.add_runtime_dependency 'activesupport', '~> 5.0'
 end

data/lib/fulmar/domain/{service/application_service.rb → model/application.rb}

@@ -1,10 +1,11 @@
 require 'rake'
+require 'fulmar/domain/service/plugin_service'
 
 module Fulmar
   module Domain
     module Service
       # The main application which extends rake
-      class ApplicationService < Rake::Application
+      class Application < Rake::Application
         def initialize
           super
           @rakefiles = %w(fulmarfile Fulmarfile fulmarfile.rb Fulmarfile.rb)
@@ -33,6 +34,9 @@ module Fulmar
           glob("#{fulmar_task_dir}/initialization/*.rake") do |name|
             Rake.load_rakefile name
           end
+          Fulmar::Domain::Service::PluginService.instance.rake_files.each do |name|
+            Rake.load_rakefile name
+          end
           super
         end
 
@@ -62,10 +66,20 @@ module Fulmar
             '-V',
             'Display the program version.',
             lambda do |_value|
-              puts "fulmar #{Fulmar::VERSION} (using rake, version #{RAKEVERSION})"
+              puts "fulmar #{Fulmar::VERSION} (using rake, version #{Rake::VERSION})"
               exit
             end
           ]
+          options << [
+              '--debug',
+              nil,
+              'Run in debug mode.',
+              lambda do |_value|
+                configuration = Fulmar::Domain::Service::ConfigurationService.instance
+                configuration.debug = true
+              end
+          ]
+          options
         end
       end
     end

data/lib/fulmar/domain/model/configuration.rb

@@ -0,0 +1,185 @@
+require 'yaml'
+require 'fulmar/domain/model/project'
+require 'active_support/core_ext/object/blank'
+require 'active_support/core_ext/hash/deep_merge'
+require 'active_support/hash_with_indifferent_access'
+
+module Fulmar
+  module Domain
+    module Model
+      # Loads and prepares the configuration from the yaml file
+      class Configuration
+        attr_accessor :environment, :target, :base_path
+        attr_reader :debug
+
+        def initialize(data, base_path = '', debug = false)
+          @data = data
+          @base_path = base_path
+          @debug = debug
+          prepare_data
+        end
+
+        # Allow access of configuration via array/hash access methods (read access)
+        def [](id)
+          ready? ? @data[:environments][@environment][@target][id] : nil
+        end
+
+        # Allow access of configuration via array/hash access methods (write access)
+        def []=(id, value)
+          if ready?
+            @data[:environments][@environment][@target][id] = value
+          else
+            fail 'Environment or target not set. Please set both variables via configuration.environment = \'xxx\' / '\
+                 'configuration.target = \'yyy\''
+          end
+        end
+
+        # Set the environment and target in one call
+        def set(environment, target = nil)
+          # For convenience, allow something like "environment:target" as string
+          if environment.class == String
+            fields = environment.split(':')
+            @environment = fields.first.to_sym
+            @target = fields.size > 1 ? fields[1].to_sym : nil
+          else
+            @environment = environment
+            @target = target unless target.nil?
+          end
+        end
+
+        # Checks if environment and target are set
+        def ready?
+          return false if @environment.nil? || @target.nil?
+          fail 'Environment is invalid' if @data[:environments][@environment].nil?
+          fail 'Target is invalid' if @data[:environments][@environment][@target].nil?
+          true
+        end
+
+        # Return the project
+        def project
+          @project ||= Fulmar::Domain::Model::Project.new(@data[:project])
+        end
+
+        def plugins
+          @data[:plugins] || {}
+        end
+
+        # Allows iterating over all targets from all configured environments
+        def each
+          @data[:environments].each_key do |env|
+            @data[:environments][env].each_pair do |target, data|
+              yield(env, target, data)
+            end
+          end
+        end
+
+        # Return the combined user and host
+        # @todo Is there another way to do this?
+        def ssh_user_and_host
+          self[:user].blank? ? self[:hostname] : self[:user] + '@' + self[:hostname]
+        end
+
+        # Handle dependencies
+        # @todo Refactor this to work with the dependencies plugin
+        def dependencies(env = nil)
+          if env.nil? || !@data[:dependencies].key?(env)
+            @data[:dependencies][:all]
+          else
+            @data[:dependencies][:all].deep_merge(@data[:dependencies][env])
+          end
+        end
+
+        # Allow access to host list
+        def hosts
+          @data[:hosts]
+        end
+
+        # Check for a feature
+        # @todo Do we still need this? Maybe replace this with a "plugin?" method?
+        def feature?(feature)
+          return @data[:features].include? feature.to_s unless @data[:features].nil?
+          case feature
+          when :maria
+            key? :maria
+          else
+            false
+          end
+        end
+
+        # Checks if a configuration key exists in one of the targets
+        def key?(key)
+          each { |_env, _target, data| return true unless data[key].nil? }
+          false
+        end
+
+        # Merge another configuration into the currently active one
+        # Useful for supplying a default configuration, as values are not overwritten.
+        # Hashes are merged.
+        # @param [Hash] other
+        def merge(other)
+          return unless @environment && @target
+          @data[:environments][@environment][@target] = other.deep_merge(@data[:environments][@environment][@target])
+        end
+
+        protected
+
+        # Prepares the configuration
+        def prepare_data
+          handle_inheritance
+          merge_hosts
+          absolutize_paths
+        end
+
+        # Merges the :all-configuration into targets.
+        # [:environments][:all] into *all* targets
+        # [:environments][:something][:all] into all targets from environment :something
+        def handle_inheritance
+          global_config = @data[:environments].delete(:all) || {}
+          environments = @data[:environments].keys
+          environments.each do |env|
+            environment_config = @data[:environments][env].delete(:all) || {}
+            targets = @data[:environments][env].keys
+            targets.each do |target|
+              local_config = @data[:environments][env][target] || {}
+              @data[:environments][env][target] = global_config.deep_merge(environment_config).deep_merge(local_config)
+              @data[:environments][env][target][:debug] = @debug
+            end
+          end
+        end
+
+        # Merges the host configuration into the targets referring to it
+        def merge_hosts
+          each do |env, target, data|
+            next if data[:host].nil?
+            host = data[:host].to_sym
+            @data[:environments][env][target] = @data[:hosts][host].deep_merge(data) unless @data[:hosts][host].nil?
+          end
+        end
+
+        # Prepends the base to the path if it is not already absolute
+        def absolutize(path, base = @base_path)
+          return base if path == '.'
+          path[0, 1] == '/' ? path : base + '/' + path
+        end
+
+        # Checks if a key is a local path
+        def local_path?(key)
+          key.to_s.split('_').last == 'path' && !key.to_s.include?('remote')
+        end
+
+        # Check all keys ending with '_path' and prepend either the
+        # @base_path or the local_path from the environment
+        def absolutize_paths
+          each do |_env, _target, data|
+            data.keys.each do |key|
+              data[:local_path] = absolutize(data[:local_path]) if data[:local_path]
+              if local_path?(key) && data[key].class == String
+                data[key] = absolutize(data[key], data[:local_path] || @base_path)
+              end
+            end
+          end
+        end
+      end
+    end
+  end
+end