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

Unconventional output when executed via rake or guard-jasmine #133

Conversation

christiannelson
Copy link
Contributor

This is a very minor issue, and possibly, more of a question than anything serious.

The output from guard-jasmine is unconventional when run via the command line (guard-jasmine) or the rake task. By unconventional, I'm specifically referring to the timestamps and INFO log level.

% guard-jasmine
08:49:44 - INFO - Guard::Jasmine starts Unicorn spec server on port 51640 in test environment (coverage off).
08:49:45 - INFO - Waiting for Jasmine test runner at http://localhost:51640/jasmine
08:49:47 - INFO - Run all Jasmine suites
08:49:47 - INFO - Run Jasmine suite at http://localhost:51640/jasmine
08:49:49 - INFO - Finished in 0.012 seconds
08:49:49 - INFO - Foo
08:49:49 - INFO -   ✔ it is not bar
08:49:49 - INFO - Bar
08:49:49 - INFO -   ✔ it is not foo
08:49:49 - INFO - 2 specs, 0 failures
08:49:49 - INFO - Done.
08:49:49 - INFO - Guard::Jasmine stops server.

That output style is consistent with what you see when running guard, but it stands out a bit outside of guard. To be clear, I would expect to see:

% guard-jasmine
Guard::Jasmine starts Unicorn spec server on port 51640 in test environment (coverage off).
Waiting for Jasmine test runner at http://localhost:51640/jasmine
Run all Jasmine suites
Run Jasmine suite at http://localhost:51640/jasmine
Finished in 0.012 seconds
Foo
 ✔ it is not bar
Bar
 ✔ it is not foo
2 specs, 0 failures
Done.
Guard::Jasmine stops server.

In my experience, most guard plugins don't include the timestamps and log level in the output of commands they execute. For example, guard-rspec doesn't add timestamps to the output of rspec.

I admit it's a cosmetic thing at worst. Regardless, are you opposed to a) dropping the timestamps and log level or b) conditionally displaying them only when run from within guard? If not, I'll try to put together a pull request for you.

Thanks!
Christian

@netzpirat
Copy link
Contributor

Whether the output has the timestamp or not is a question of using the Guard provided UI helper or not. Since guard-rspec just delegates the work to RSpec, which in turn just writes to stdout through a formatter, it doesn't have the Guard logger timestamps. Guard-Jasmine itself doesn't make use of an external tool and uses the UI helpers, so all its output is configurable by Guard.

To change this you have basically two options:

  1. Change the result formatter to not use the UI helpers and make a pull request (Sorry, I'm quite short on time since it's shortly before the summer holidays and way too much happens right know with three kids in school) I'd do that only for outputting the actual result and keep them for stuff like server starting, etc. since we give the users the possibility to decide whether they want the timestamp or not (see next point).
  2. Configure the logger either in your Guardfile or the shared configuration to just not have such verbose timestamps.

I hope that helps.

@christiannelson
Copy link
Contributor Author

Thanks for the detailed response. I'm happy to submit a pull request once I know you're okay with the change.

The logger directive in the Guardfile only applies when running guard. That's not the scenario where the output is "unconventional". It's when running guard-jasmine directly on the command line or via the rake task. In both those cases, the logger directive does not apply. As far as I can tell, there is no way to configure a logger in those cases that drops the timestamp and log level.

A fix would look roughly like: detect when guard-jasmine has been invoked via guard, and follow the existing code path. When not run by guard (i.e. rake or direct on the command line), bypass guard's logging facility or tweak its configuration so that the timestamp and level are not displayed.

If that sounds reasonable, I'll look for a clean way to implement it.

@netzpirat
Copy link
Contributor

The logger directive in the Guardfile only applies when running guard. That's not the scenario where the output is "unconventional". It's when running guard-jasmine directly on the command line or via the rake task. In both those cases, the logger directive does not apply. As far as I can tell, there is no way to configure a logger in those cases that drops the timestamp and log level.

Good point, I always forget about this.

A fix would look roughly like: detect when guard-jasmine has been invoked via guard, and follow the existing code path. When not run by guard (i.e. rake or direct on the command line), bypass guard's logging facility or tweak its configuration so that the timestamp and level are not displayed.

A very simple fix is to just configure the logger options in lib/guard/jasmine/cli.rb, e.g.

::Guard::UI.options = ::Guard::UI.options.merge({ :template => ':message' })

or even make the logger template a simple string option for the command line with a default.

If that sounds reasonable, I'll look for a clean way to implement it.

That would be great!

…nd log level so that our output looks more like other commands.
@christiannelson
Copy link
Contributor Author

Your "very simple fix" works fantastically. If excluding the timestamps and log level for the CLI is okay with you (it's perfect for me), I don't think there's really a simpler solution. I personally have a hard time imagining someone using a command-line option to change the log format.

@netzpirat
Copy link
Contributor

Absolutely, I think no one needs to see a timestamp on the CI server for Guard:Jasmine. We need to provide sensible defaults and not a configuration option more to confuse the users completely.

@netzpirat netzpirat merged commit a91587d into guard:master Jun 26, 2013
@netzpirat
Copy link
Contributor

Oops, how could I forget about this? Finally merged and will release today. Thanks a lot!

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

Successfully merging this pull request may close these issues.

None yet

2 participants