Currently @actions/core provides debug(), error() and warning(). These do not cover the use case of logging information that you would like to always show in the logs but are not necessarily an error or warning of an issue.
Add an info variant to the logging provided by @actions/core
I think you can do this with a simple console.log statement, is there a use case where something else is necessary?
I believe this is the case, but it seems odd that you would use debug(), error() and warning() from @actions/core and then just use a built-in console.log otherwise. I would expect that all of the logging should occurring using methods from the same object.
I think the difference is that our runner has built in commands for debug/error/warning so that it processes them differently (e.g. color coding), while there's no command for info (and it doesn't really make sense for there to be one). I think I'd personally be more confused by why a function like that would exist/would assume it was hooked up to a special runner command as well.
Okay, I am happy to use console.log.
As a data point in terms of discoverability/intiutation (and its obviously just a single data point), I expected the info() method to exist as there is a section for Logging Commands, so I figured that would be how all of my logging should be done.
https://github.com/actions/toolkit/blob/2a1b7d5c7e080e8500b1b19b5af02b4ab049bc68/packages/core/src/core.ts#L107
I was confused by this at first too. Once I realized what the core.debug() etc. functions did it made sense why there wasn't one for info. It could be useful to mention this in the docs.
I've been considering creating my own logger that uses the methods from this package when available, and then fall back to console for the rest. That way I have a consistent logging experience.
Another option was to use console everywhere and then replace console.debug etc. with the copies from this package. This would also work better with other packages that use the console functions.
Hm, I think as I consider this more I'm actually convinced that we should have this. Thanks for the feedback.
Ultimately, while the other logging functions do have special implementations on the runner, we're exposing a logging interface and the author shouldn't have to understand that distinction. Addressed in #111
Most helpful comment
Hm, I think as I consider this more I'm actually convinced that we should have this. Thanks for the feedback.
Ultimately, while the other logging functions do have special implementations on the runner, we're exposing a logging interface and the author shouldn't have to understand that distinction. Addressed in #111