-
Notifications
You must be signed in to change notification settings - Fork 484
Guardfile examples
ignore %r{^ignored/path/}, /public/
filter /\.txt$/, /.*\.zip/
notification :growl_notify
notification :gntp, :host => '192.168.1.5'
group :frontend do
guard :bundler do
watch('Gemfile')
end
guard :pow do
watch('.rvmrc')
watch(%r{^\.pow(rc|env)$})
watch('Gemfile.lock')
watch(%r{^config/.+\.rb$})
end
guard :livereload do
watch(%r{^app/.+\.(erb|haml)})
watch(%r{^app/helpers/.+\.rb})
watch(%r{^public/.+\.(css|js|html)})
watch(%r{^config/locales/.+\.yml})
end
end
group :backend do
guard 'spork', :wait => 50 do
watch('Gemfile')
watch('Gemfile.lock')
watch('config/application.rb')
watch('config/environment.rb')
watch(%r{^config/environments/.+\.rb})
watch(%r{^config/initializers/.+\.rb})
watch('spec/spec_helper.rb')
end
guard :rspec, :version => 2, :cli => "--color --drb -r rspec/instafail -f RSpec::Instafail", :bundler => false, :all_after_pass => false, :all_on_start => false, :keep_failed => false do
watch('spec/spec_helper.rb') { "spec" }
watch('app/controllers/application_controller.rb') { "spec/controllers" }
watch('config/routes.rb') { "spec/routing" }
watch(%r{^spec/support/(requests|controllers|mailers|models)_helpers\.rb}) { |m| "spec/#{m[1]}" }
watch(%r{^spec/.+_spec\.rb})
watch(%r{^app/controllers/(.+)_(controller)\.rb}) { |m| ["spec/routing/#{m[1]}_routing_spec.rb", "spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb", "spec/requests/#{m[1]}_spec.rb"] }
watch(%r{^app/(.+)\.rb}) { |m| "spec/#{m[1]}_spec.rb" }
watch(%r{^lib/(.+)\.rb}) { |m| "spec/lib/#{m[1]}_spec.rb" }
end
end
The frontend dev would launch Guard like this: [bundle exec] guard -g frontend
While the backend dev would launch it like this: [bundle exec] guard -g backend
Example of excluding files started with dot:
guard 'livereload' do
watch(%r{app/.*/[^.][^/]+\.(erb|haml|slim)})
watch(%r{app/helpers/.*/[^.][^/]+\.rb})
watch(%r{public/(.*/[^.][^/]+\.(css|js|html))}) {|m| m[1] }
watch(%r{app/assets/(.*/[^.][^/]+\.css)(\.s[ac]ss)?}) { |m| "/assets/#{m[1]}" }
watch(%r{app/assets/(.*/[^.][^/]+\.js)(\.coffee)?}) { |m| "/assets/#{m[1]}" }
watch(%r{config/locales/[^.].+\.yml})
end
Using 2 guard-rspec: 1 for spork, 1 for unit tests
I have adopted Avdi Grimm's naming convention for integration specs: *_integration_spec.rb
I use Spork for specs which load the full rails stack such as controllers, integration models specs, ... For models unit tests and libs, I don't want the overhead of Spork.
The challenge was to come up with a simple regex using "Negative lookbehind assertion" in order to avoid running specs twice each time a file is saved.
group 'tests-with-spork' do
guard 'rspec', :version => 2, :cli => "--drb", :all_after_pass => false do
watch('spec/spec_helper.rb') { "spec" }
watch(%r{^spec/controllers/.+_spec\.rb$})
watch(%r{^spec/models/.+integration_spec\.rb$})
watch(%r{^spec/helpers/.+_spec\.rb$})
watch(%r{^spec/routing/.+_spec\.rb$})
watch(%r{^spec/requests/.+_spec\.rb$})
watch(%r{^app/models/(.+)\.rb$}) { |m| "spec/models/#{m[1]}_integration_spec.rb" }
watch(%r{^app/helpers/(.+)\.rb$}) { |m| "spec/helpers/#{m[1]}_spec.rb" }
watch(%r{^app/controllers/(.+)_(controller)\.rb$}) do |m|
[
"spec/routing/#{m[1]}_routing_spec.rb",
"spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb"
]
end
watch(%r{^spec/support/(.+)\.rb$}) { "spec" }
watch('config/routes.rb') { "spec/routing" }
watch('app/controllers/application_controller.rb') { "spec/controllers" }
watch(%r{^spec/lib/.+_integration_spec\.rb$})
end
end
group 'unit-tests' do
guard 'rspec', :version => 2, :all_on_start => false, :all_after_pass => false, :bundler => false do
watch(%r{^lib/(.+)\.rb$}) { |m| "spec/lib/#{m[1]}_spec.rb" }
# ?<! Negative lookbehind assertion: ensures that the preceding characters do not match 'integration',
# but doesn't include those characters in the matched text
watch(%r{^spec/models/.*(?<!integration)_spec\.rb$})
watch(%r{^spec/lib/.*(?<!integration)_spec\.rb$})
end
end
This wiki and the Guard README document contain a lot of information, please take your time and read these instructions carefully.
If you run into any trouble, you may start by understanding how Guard works.
We provide detailed changes for each Guard release.
Be sure to read the CONTRIBUTING guidelines before reporting a new Guard issue or open a pull request.
If you have any questions about the Guard usage or want to share some information with the Guard community, please go to one of the following places:
- Google+ community
- Google group
- StackOverflow
- IRC channel
#guard
(irc.freenode.net) for chatting