Accept an option to dump log output to github Job Summaries

[jasonkarns]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Current log output is not the greatest for digging into violations on github actions.

Expected Behavior

Now that github actions has Job Summaries, it would be awesome if super-linter's log output could be redirected directly to the job summary. That way the linter output could be easily consumable from the job page instead of diving into the logs.

Anything else?

No response

[ferrarimarco]

This is an interesting request. Adding it to the backlog.

[jasonkarns]

In the (present) absence of an official feature, is there any existing way to redirect the log output to the job summaries file descriptor now?

I've tried:

      - uses: github/super-linter/slim@v6
        env:
          # /snip
          CREATE_LOG_FILE: true
          LOG_FILE: ${{ github.step_summary }}

but that fails:

mv: cannot move '/tmp/tmp.zGd3tC9yAF' to '/github/workspace//github/file_commands/step_summary_a2525f8f-5bd7-40c1-9437-d3d36f44bdf2': No such file or directory

[jasonkarns]

I've also tried just catting the log file to the summary descriptor but that failed.

Run cat super-linter.log >> $GITHUB_STEP_SUMMARY
  cat super-linter.log >> $GITHUB_STEP_SUMMARY
  shell: /usr/bin/bash -e {0}
cat: super-linter.log: Permission denied
Error: Process completed with exit code 1.

Opened #5658 for logfile permissions error.

[echoix]

I'm not sure that what you'd want as a final solution would work with the current limitations of job summaries.
There is a size limit of the output that can be added to that file. With some linters (I have xmllint in mind), the output in one of my projects was so long that even with the log viewer my browser (on desktop) had a really hard time getting through. The job summary should thus be for a job summary, not the complete logs or linter outputs.

For your other issue, you must also keep in mind that the way to write to the job summary is to write to a file that has a path given by an env variable. That file changes for every step, and also had its limits, so a bad step won't break markdown formatting for the subsequent steps that did it correctly. If super-linter is using a composite action type, I don't know how the definition of step is applied (is the whole action a same step, or each step in the composite action given a GITHUB_STEP_SUMMARY?). If it is a docker type, I would expect that in addition to having the GITHUB_STEP_SUMMARY variable available, that temp folder must be also accessible from inside docker (does GitHub's action runner do it for us for any container launched with the docker action type?). Only after that, I finally would suspect a permission error, as concluded in the issue.

In conclusion, this suggestion might need to be refined a bit to be realistic. And to not duplicate what the CI logs are already designed for. And to keep in mind what the job summary would look like when super-linter is only one of the steps in a workflow's job.

[jasonkarns]

The job summary should thus be for a job summary, not the complete logs or linter outputs.

Completely agree. Ideally, i'd probably like to see the summary only include ERROR output (possibly with a configurable level but certainly defaulting to WARN or ERROR). And better still, the output could collapse each lint tool's output in distinct <details> elements so they're easily read.

However, at the moment, the LOG_LEVEL option doesn't affect the output log file so current configuration isn't flexible enough to handle this. (Not to mention, the output log is not even readable within a workflow due to #5658 ) So with the current limitations, a first-class summary support is necessary beyond simply dumping the log file.

And to keep in mind what the job summary would look like when super-linter is only one of the steps in a workflow's job.

Also agree. This feature request is just a broad strokes idea to remedy the issue of super-linter's output being nearly unreadable. There are a number of options to address this in a way that allows users to direct output in ways they find more consumable.

For instance, if the logfile were readable in github workflows, then users could manipulate the output log in subsequent steps. If log-level were to affect the log's contents, subsequent filtering wouldn't be necessary. Regardless, simple sed/grep could handle this. But asking for those features without the grander user-case in mind could lead down the wrong path. So this feature request is the desired destination (legible linter messaging at the job level), with no prescriptions about how that is accomplished.