Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it time to restore the #run_on_additions hook? #391

Open
javmorin opened this issue Nov 29, 2016 · 5 comments
Open

Is it time to restore the #run_on_additions hook? #391

javmorin opened this issue Nov 29, 2016 · 5 comments

Comments

@javmorin
Copy link

Environment:

  • Ruby 2.3.1
  • Guard 2.14.0
  • Guard::RSpec 4.7.3
  • Atom 1.12.5
  • Emacs 25.1
  • Gedit 3.22
  • Vim 8.0.0086

A while back (2014-ish) Guard::RSpec had both #run_on_modifications and #run_on_additions hooks defined. This was then switched to a single #run_on_changes hook. Using #run_on_changes apparently caused some users (especially those using vim) to experience multiple spec runs for file changes and so the #run_on_changes hook was reverted back to using #run_on_modifications; the #run_on_additions hook was not restored.

Fast forward to today, when I open and save a new file with atom, emacs, gedit or vim I see no test runs. If I touch the file, or make a further change and save it, the spec runs properly. I should also note that all but emacs are running in their default configuration (no cusomization of save behaviors). Emacs is fairly customized as it's my editor of choice, but save behavior should be the default.

Given the above, if I add the following code block to my Guardfile...

class Guard::RSpec
  def run_on_additions(paths)
    return false if paths.empty?
    _throw_if_failed { runner.run(paths) }
  end
end

... creating and saving a new spec file in each of the editors now results in guard-rspec running the newly created spec properly (once). The guard debug output shows only the #run_on_additions hook being triggered. I tried unsuccessfully to investigate further, but it would seem that the Guard implementation may now be smarter about create vs modification events and filters out duplicate/extraneous hooks.

I would be happy to attach a pull request to enable the additions hook if there is interest in it, but thought it best to test the waters first.

@jayniz
Copy link

jayniz commented Dec 13, 2016

Interesting. For me it's the other way around (editing on osx, guard running in a docker container with the host's source directory mounted): saving with sublime, textmate and so forth works, whereas saving with vim goes unnoticed by guard-rspec. See guard/listen#420

@javmorin
Copy link
Author

@jayniz in your case is the issue occurring for new files being saved as well, or an just for existing files being modified? It appears from your referenced issue that you are just seeing problems with modifications to files being noticed,

@jayniz
Copy link

jayniz commented Dec 13, 2016

@javmorin the problem in my case is, that I never get modification events - I always get addition events, even when changing a file (with (neo)vim). With other editors (sublime, atom, etc.) it works as expected.

@ac21
Copy link

ac21 commented Apr 2, 2019

+1; using vim (mac) with guard running in docker (ubuntu). saving in vim triggers :run_on_additions whereas saving with other editors or invoking touch on the file triggers :run_on_modifications.

@dmcnally
Copy link

+1; I've been trying to understand why my tests don't get run on and off for months when running guard inside a docker container. Finally decided to investigate and eventually with the right google incantation came across this issue. I could use --force-polling which works but hammers the disk and battery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants