Split log output into groups for better readability

[Tyrrrz]

Context

Currently, the logs coming from v2.0-alpha versions of the action are borderline unreadable -- there's just too much information. This makes it very difficult to trace down build errors.

Suggested solution

GHA supports line grouping: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#grouping-log-lines

Instead of printing 7000 unseparated lines, they could be separated into logical groups, perhaps one for each step of the process. That way you can more easily inspect different sections of the log.

Considered alternatives

Additional details

[webbertakken]

Hi @Tyrrrz and thank you for your suggestion.

I agree the logs are a hard to read. They can also still be useful, as most of the time you'd be searching for "error" in the log as a whole. I would consider this a potential blocker for splitting up the logs too much.

That said; ideally we could definitely split between activate, build and return license steps. This would mean that we have 6900 lines in the build step, which is not helping your cause.

What would you suggest we do to split the output from unity editor itself? Do you have any experience utilising the line grouping effectively? Would love to hear some more ideas on how to implement this well.

Maybe there are also alternatives to consider, like creating a better summary at the end somehow.

[Tyrrrz]

Hey @webbertakken

I haven't had the experience of utilizing line grouping myself. Looking at the log, I'm thinking maybe the following separation would make sense:

1. Pull Docker image
2. Activate license
3. Restore packages
4. Import assets (this one spans thousands of lines)
5. Compile scripts (for some reason after this it starts importing assets all over again)
6. Build artifacts (this yet again starts importing assets)

The biggest issue currently is that it's very hard to tell where one logical step ends and another one starts. Also, some steps like "importing assets" produce a lot of logs, which by themselves are not useful in any way, so it would really be nice if they were collapsible. All of this makes it difficult to find errors, as they are often somewhere in the middle, requiring you to sift through a sea of unrelated information.

[webbertakken]

Yea we need to call in the bash tricksters. 👩‍🔬👨‍🔬

@GabLeRoux, @mob-sakai any ideas how we could implement this?

[davidmfinol]

We can easily create a group for the first step by wrapping the Docker build in index.js:

    core.startGroup('Preparing Docker image....');
    const builtImage = await Docker.build({ path: actionFolder, dockerfile, baseImage });
    core.endGroup()
    await Docker.run(builtImage, { workspace, ...buildParameters });

Then I think we could add the echo "::group::my title" and echo "::endgroup::" at the start and end of each of the activate.sh, build.sh, and return_license.sh steps.

The problem is that the steps you listed as steps 3-6 are all internal to the unity editor, so I don't know how we could split those steps up into groups. Hopefully the others may have some more ideas.

[Tyrrrz]

Hmm, I didn't realize they were internal to the editor, my bad.
I don't suppose Unity's CLI has some sort of "verbosity" parameter?

Another (wild) idea: reroute Unity's logs to a file (using -logFile option) and when/if the build fails, print only the last 100 lines to the console.

[webbertakken]

There are some other flags we might be able to use for better readability.

We could add the -stackTraceLogType full flag and argument.

There's an undocumented -cleanedLogFile flag, which can be used together with -logFile. The former used to support only files (and not stdout), but it might have been fixed since.

[mastef]

For more refined controls of stackTraceLogType you can use this in your project :

#if UNITY_EDITOR
using UnityEditor;
using UnityEditor.Build;
using UnityEditor.Build.Reporting;
using UnityEngine;

class OnBuild : IPreprocessBuildWithReport
{
    public void OnPreprocessBuild(BuildReport report) {
        // EditorUserBuildSettings.androidCreateSymbolsZip = true;
        Application.SetStackTraceLogType(LogType.Log, StackTraceLogType.None);
        Application.SetStackTraceLogType(LogType.Warning, StackTraceLogType.ScriptOnly);
        Application.SetStackTraceLogType(LogType.Error, StackTraceLogType.ScriptOnly);
    }
}
#endif

It will then remove stacktraces from Debug.Log but keep shorter ones for other types.

[webbertakken]

This should become part of the CLI (nice to have).

I'm adding this to the Roadmap to v3.0.0.