feat(runner): Config option to prevent logging to the console twice

[is-already-taken]

This might be the case when Karma.run() is called inside the same
process/terminal as the server is running in (e.g. development
servers).

Fixes #2121, #2799

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[is-already-taken]

I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[johnjbarton]

If I understand correctly, you want to prevent output by runner and by reporter?

In general I want to avoid adding yet more and more and more options. This makes our code hard to understand and test.

Why not remove the reporter in the config?
Why not remove the logging in the runner altogether?
Why not make the logging in the runner based on logLevel setting?

[is-already-taken]

Thank you for your response.

If I understand correctly, you want to prevent output by runner and by reporter?

Correct.

In general I want to avoid adding yet more and more and more options. This makes our code hard to understand and test.

I understand that.

Why not remove the reporter in the config?

If you mean removing it from the server's config then there would be no reporting at all since (to my understanding) the runner is just echoing the output of the reporter. That's not feasible. Please clarify.

Why not remove the logging in the runner altogether?

Can't reliably tell whether this is sarcasm or if I just don't understand. Please clarify.

Why not make the logging in the runner based on logLevel setting?

I like that one. Would it be acceptable if the runner accepts logLevel just like the server and only echoes the reporter results on level config.LOG_DEBUG? This means that logLevel can be applied in two different places: via the server config / switches and via the runner config / switches. In the runner context this would not configure the runners logger but control the process.stdout.write()

I might change the feature this way if you're fine with it.

[johnjbarton]

I don't use the 'runner' part; I don't really know how it works. My suggestion about not logging in the runner is: if the reporter is logging the result why does the runner need to echo that?

To say it another way: was the original feature -- re-log the result in runner -- misdesigned?

[is-already-taken]

I think the original idea was, to have the server running in one terminal or even on one host and have the runner connect to that, be it from another terminal or even host. In that case, you want to see the reporter output there. In this context streaming out the reporter results from the socket to the terminal was "good enough". Though I'm not the maintainer, so I'm not 100% sure if that was the idea.

Now, since we're kicking off the runner in same process as the server, they share the same terminal, hence there should be a option to control the runners outputs.

Another approach proposed in the referenced #2121 was to have the runner emit an event. In that case the CLI would have to listen to that event.

[johnjbarton]

Can you take a look at the alternative in #2121?

[is-already-taken]

A friendly review reminder.