Super-linter: OUTPUT_LOG option

[dskvr]

Is your feature request related to a problem? Please describe.
Browsing linter errors and warnings in the Actions GUI is not a pleasant or efficient experience.

Describe the solution you'd like
Something like an OUTPUT_LOG or LOG_FILE option that adds the super-linter output to a logfile. The case this would benefit is the ability to use upload-artifact to upload the linter logs as an artifact that could be downloaded directly or through another workflow/job and/or integration (for example, posting the log to a slack channel).

Yes, "raw logs" options in a job enables a suboptimal workaround for this functionality, requiring 4 clicks and wading through all the other the step outputs (this is what I'm doing now)

Describe alternatives you've considered
Abandon super-linter entirely and initialize linters through bash so that a logfile can be generated, for example:

pylint | tee "pylint.log"

[zkoppert]

I think this is a great suggestion. Is this something that you are interested in implementing @dskvr or should we put out a call for others to jump on development?

[dskvr]

I have not looked into the implementation of linters in super-linter. I'll check it out tomorrow and let you know of it's something I can pick up.

[nemchik]

@dskvr i've started a draft and specifically want to ask if https://github.com/github/super-linter/pull/486/files#diff-2b006ea0cfcfac29e33a1b9eef9974c1R1026 would be what you're looking for. I've not yet made a variable for the location, but that could be done as well. For the moment all the logs end up in the predefined file.

[dskvr]

Hey, sorry I didn't check on this yesterday, woke up to a mean stack trace.

@nemchik At first glance it looks pretty usable, I'll give it a try this evening if time permits.

[nemchik]

Sounds good. P.s. I'm not finished making ALL the output go to the log yet, just preliminary stuff so far.

[dskvr]

It's definitely working, but as you said, it's not outputting _everything_ (it's technically enough for me to use it right now). I can see how filename could be helpful, though I cannot imagine that it would be a blocker for myself or anyone else 🤔 .

Additional nice-to-haves I randomly thought of are

1. only_on_error: only outputs error logs, not success logs or better yet..
2. log_level (int) or log_type (array): specify a level integer (difficult to coalesce and transpose across many linters) or an array of log types (notice, warning, etc...)
3. include (array): Inclusion pattern excludes all by default when != empty and only includes errors from defined linters.
4. split_files (bool): output log for each linter individually (named after linter) <- this one satiates same need the include one above would solve and likely be easier to maintain

All of those argument signatures could probably use some love if anything like that were pursued.

Let me know if you need to pass off the PR. I'm going to be busy for the foreseeable future but can make time if needed. Cheers.

[nemchik]

1. only_on_error: only outputs error logs, not success logs or better yet..
   Let's go with option 2
2. log_level (int) or log_type (array): specify a level integer (difficult to coalesce and transpose across many linters) or an array of log types (notice, warning, etc...)
   This is doable and the functions are already setup for this, it'll just be a matter of swapping notice for info in most cases and then adding functionality to set verbosity level (which I have already set aside).
3. include (array): Inclusion pattern excludes all by default when != empty and only includes errors from defined linters.
   This would be redundant to just disabling the linters you don't want using the existing environment variables? Maybe I am misunderstanding this request. If you don't want the output from a specific linter to be logged would you not just disable that linter?
4. split_files (bool): output log for each linter individually (named after linter) <- this one satiates same need the include one above would solve and likely be easier to maintain
   This may be the trickier one, so we might handle that in a separate PR as it also relates to come other ideas.

From here since it sounds like we're on the right track the remaining tasks on the PR will be to replace all lines that currently produce loggable output with log functions (so the log file is used) and to add the code to allow setting the verbosity level. I'll update my notes in the PR and try to have this done soon so we can review/merge the PR.

[dskvr]

This would be redundant to just disabling the linters you don't want using the existing environment variables?

Good point

This may be the trickier one, so we might handle that in a separate PR as it also relates to come other ideas.

Makes sense to me.