This should get Travis builds working again, and fixes a few other things.
Please don't merge until the Travis build for the pull request is green.
.gitignore: add coverage/ subdirectory
tag Guard.setup_signal_traps spec as slow
This allows these examples to be excluded via
rspec -t ~speed:slow
include guard-rspec in test group environment since it's required by …
This fixes the breakage introduced by 613b11d into Travis builds.
Coverage increased (+0.1%) when pulling c90f42b on aspiers:master into 8f8f01e on guard:master.
Thanks @aspiers , tmux specs failed on 2.0.0 & jruby-18mode can you have a look please? Thanks!
Yeah I'm already looking - I half-expected those failures ... I have seen them on 1.9.3 too.
@thibaudgg I'm struggling to understand why @rudicode added tmux set quiet on/off in d045182 - do you know?
tmux set quiet on/off
No idea, I don't use tmux myself.
Revert silent discard of NoMethodError from plugins introduced by 95d…
…9cd1 (fixes #413)
Rather than silently discarding all NoMethodErrors, we just check
whether the plugin implements the task and only execute it if it does.
refactor invocation of tmux client
prevent tmux output from messing up spec output
Don't worry, I've worked around it ...
Coverage increased (+0.11%) when pulling ed1bb0f on aspiers:master into 8f8f01e on guard:master.
Alright! I think this is good to merge now. Please sanity check b5a2f01 first though - that is the only risky commit. All the others are very low risk.
You forgot to update the changelog! :)
I was actually saying this to @aspiers (you can now directly update and push it without a pull-request)! ^^
Really good point! :)
I know I have push access (thanks for that ;-) but I think it's a bad idea to push directly because it makes the changes less visible and also circumvents Travis - it was a direct push which broke Travis last time...
You're right, I shouldn't have "direct pushed" (aka [ci skip]), my bad!
That said, I think the actual issue was that the test needed the guard-rspec gem to be loaded! Fortunately, I've fixed that with 762524c. :)
That said, for the Changelog I really encourage you to direct push with [ci skip] (or without if you're really afraid to break the build). ;-)
I didn't know about [ci skip] before - that explains the previous breakage. However, it is orthogonal to direct pushes. Even if you issue a pull request containing [ci skip], it still gives other people a chance to peer review your changes. This is good even when altering READMEs etc. because documentation can have bugs too :) So I would suggest that it is a good idea to never direct push except for real emergencies.
I would have updated the CHANGELOG.md but there are no instructions on how to add new sections after a release. Currently VERSION is still 1.7.0 but new changes cannot go in the 1.7.0 section of CHANGELOG.md. I've just looked at the history and it seems that creating a new ## Master section is the way to go.
Sorry, I thought you were speaking about [ci skip], I understand what you meant now!
You're right there's no guidelines for updating the Changelog, I'll try to write them down soon! :)
And yes, we use ## Master when changes are not included in a gem release yet.
In the end, it's really up to you to choose to submit pull-requests for readme/changelog/docs changes, but don't worry we'll never complain about new pull-requests! ^^