# CaptainHoog [![Build Status](https://travis-ci.org/GateprotectGmbH/captain_hoog.svg)](https://travis-ci.org/GateprotectGmbH/captain_hoog) [![Code Climate](https://codeclimate.com/github/GateprotectGmbH/captain_hoog/badges/gpa.svg)](https://codeclimate.com/github/GateprotectGmbH/captain_hoog) Okay. That's not such a funny gem name. But it's a reference to Git and the subject of the gem: the Git Hooks. ## Installation Add this line to your application's Gemfile: gem 'captain_hoog' And then execute: $ bundle Or install it yourself as: $ gem install captain_hoog ## Usage ### Install the hook ``` hoog install --type --plugins_dir --project_dir ``` Captain Hoog will install also a global ```.hoog``` directory in ```$HOME```. It will also pull the default hookins. If you don't want to have this pulled, use the ```--skip-hookins``` flags. **Please note:** `````` and `````` must be given as absolute paths. `````` and `````` are also optional. Also make sure to run this from your git repository's root folder. ```GIT_HOOK_TYPE``` may be something like this * pre-commit (default) * pre-push * pre-rebase * pre-applypatch If the directory where pre-git test should be done, differs from the working directory adjust: ``` --project_dir ``` to your needs. You can omit this. ``` --plugins_dir ``` is not required anymore. If it's omited it will point to the actual directory you run the install script from. It should point to the directory you store the CaptainHoog plugins. _A note about plugin directories:_ To have more than one plugin directory used, just add as many plugin directories as you want do the ```plugins_dir``` section in the Hoogfile. You can select which plugin is called from which Git hook later by defining it in the Hoogfile. ### Removing the hook Remove a hook by using the ``` hoog remove --type ``` command. where `````` is ```pre-commit``` by default. ### The Hoogfile All plugin executable and ignoring power is configurable in the Hoogfile. The Hoogfile's name is ```hoogfile.yml``` and it will be installed in your Git root directory. If you install several hooks, the installer will ask you if you want to override the config file. The Hoogfile has several sections: * hook plugins per type * project dir * plugins dir Some options are predefined from your information you provided during installation: * project dir * plugins dir If this did not matches your need anymore, just pass the new paths in there. Captain Hoog is doing nothing by default. You have explicitly define which plugins it should run or which not. You do this per hook type. E.g. for ```pre-commit```: ``` pre-commit: - cucumber - rspec ``` So the plugins named **cucumber** and **rspec** are running before your commit applies to the index. ### Migrating from pre 1.0 versions There is no migration path from previous versions. Just re-install and adjust the Hoogfile to your previous configuration. ### Writing plugins A CaptainHoog plugin is written with a very simple DSL that used with the following expressions: * ```test``` * ```message``` * ```helper``` * ```run``` Within ```test``` any stuff is done that either forces the commit to exit or to pass. Whatever you want to do like syntax checking, code style checking - implement it and make sure you return a boolean value. ```message``` is used to define a notification that is shown to the user if the test **fails**. This obviously must return a String. You have to add a description (or name) to your plugin, this description (or name) will be used to check if the plugin should be executed or not by adding the plugins name to the section of your Hoogfile. ```rb git.describe 'sample' do |pre| pre.test do # do any test like code style guide, syntax checking... # Must return a boolean value. end pre.message do # Define a message string here that is shown if the test fails. # The message is printed out in red per default. If you don't want # a color pass color: :none to the helper method. Or if you want a # specific color, the color as symbol: # pre.message(color: :none) do .... end end ``` With ```helper``` you can extract some logic into a helper method that is useable anywhere in the plugin. ```rb git.describe 'logger' do |pre| pre.helper :collect_logger_outputs do # do something end pre.test do collect_logger_outputs.empty? end pre.message do %q{ You have some logger outputs in your code! } end end ``` If you don't want to test anything before commiting or pushing thus just running a command or something similiar, use the ```run``` method. ```rb git.describe 'name of Git head' do |pre| pre.run do system "git show --name-only HEAD" end end ``` Within all expressions you can use the ```env``` variable which provides you the context the plugin is run in: ```rb git.describe 'output the plugin context' do |pre| pre.run do puts env.context # might be 'pre-commit, pre-push etc ... end end ``` **Plugin file structure** A common way to organize plugins is: ``` / - .rb - test/ - _[spec|test].rb ``` **Plugin specific configurations** Sometimes a plugin needs specific configurations that not match the use of a helper method. You can add plugin configurations to your Hoogfile by adding a section that is named after the plugin. Let's say there is a plugin called 'clear logs' that needs a 'truncate_line_numbers' configuration. The Hoogfile section would look like: ```yaml clear logs: truncate_line_numbers: 100 ``` You are able to access this configuration within your plugin by using the ```config``` method: ```rb git.describe 'clear logs' do |pre| pre.run do system "sed -i '#{config.truncate_line_numbers},$ d' development.log" end end ``` ## Test Support ### Sandbox For testing purposes, Captain Hoog uses some kind of sandboxing. You're able to use the sandbox directly (you have to do this by now for any other test frameworks than RSpec). Using the sandbox is easy: ```ruby sandbox = CaptainHoog::Test::Sandbox.new(plugin_code, cfg) sandbox.run # then have full access to the plugin by using sandbox.plugin ``` You have to pass the plugin as String or File object and a configuration hash to the sandbox. The configuration hash might consist of a global (the ```env```) and a plugin specific configuration (marked by using the plugins name as key). Example: ```rb plugin_code = <<-PLUGIN git.describe 'foo' do |hook| hook.helper :foo_helper do config.number end hook.test do foo_helper true end hook.message do 'Fun' end end PLUGIN cfg = { env: { suppress_headline: true }, plugin: { foo: { number: 12 } } } sandbox = CaptainHoog::Test::Sandbox.new(plugin_code, cfg) sandbox.run sandbox.plugin.result[:test] # => true sandbox.plugin.foo_helper # => 12 sandbox.plugin.result[:message] # => Fun ``` **Note** that the sandbox will not provide you some fake file system. ### Frameworks Captain Hoog provides some small DSL for testing plugins if you're using RSpec. For the use of MiniTest (or any other testing framework, see the section below.) ### RSpec Require test support by using ```rb require 'captain_hoog/test' ``` There is no configuration needed, Captain Hoog will detect if you're using Rspec. Then - as usual - add a ```describe``` block. Within this block you have access to a block helper: ```rb with_plugin :, config: , silence: do # .... end ``` |Argument| Description| |:-------|:-----------| |PLUGIN_NAME | Plugin - as String or File object (given as a ```let``` or method) | |config | plugin configuration, see **Sandbox** section for details. | |silence | Truthy or falsy value, silences the plugin output | With ```with_plugin``` you have full access to the Captain Hoog plugin by using ```plugin```. A full example: ```rb require 'rspec' require 'captain_hoog/test' describe 'Test for hook' do let(:divide) do path = File.expand_path(File.join(File.dirname(__FILE__), '..', 'fixtures', 'plugins', 'test_plugins', 'divide.rb')) File.new(path) end let(:config) do { plugin: { divide: { divider: 12, compare_value: 1 } } } end with_plugin :divide, config: :config, silence: true do describe 'helpers' do describe '#divider' do it 'returns 12 as Fixnum' do expect(plugin.divider).to eq 12 expect(plugin.divider).to be_instance_of Fixnum end end describe '#check_equal' do it 'returns 1' do expect(plugin.check_equal).to be 1 end end end it 'exits with true' do expect(plugin.result[:test]).to be true end end end ``` ### Other Test Frameworks (MiniTest, TestUnit ...) You have to use the sandbox directly. See an example using MiniTest below. ```rb gem 'minitest' require 'minitest/autorun' require 'minitest/unit' require 'captain_hoog' require 'captain_hoog/test' class DividePluginTest < Minitest::Test def setup config = { env: { suppress_headline: true }, plugin: { divide: { divider: 12, compare_value: 1 } } } path = File.expand_path(File.join(File.dirname(__FILE__), '..', 'fixtures', 'plugins', 'test_plugins', 'divide.rb')) sandbox = ::CaptainHoog::Test::Sandbox.new(File.new(path), config) sandbox.run @plugin = sandbox.plugin end def test_helper_divider assert_equal @plugin.divider, 12 end def test_helper_divider_class assert_instance_of Fixnum, @plugin.divider end def test_result assert_equal plugin.result[:test], true end end ``` ## Last stuff Init and written by Daniel Schmidt (daniel-a.schmidt@rohde-schwarz.com) Image "Captain Hook" © 2012 Brian Patterson