chore(ci): CI grouping and refactoring

[dcvz]

Checklist

• Confirmed that run-checks all script has been executed.
• Made sure the book is up to date with changes in this PR.

Changes

Improvements to CI Output:

• Groups logs making them collapsible and easier to read / debug.
• Updates the time duration output
• Replaces our CI_RUN for standard CI env

Examples Output

STD Output

[antimora]

LGTM!

[Luni-4]

Thanks a lot!

I propose to change println! with debug! or info! macros, which can be enabled through filters.

Here an example of how to do that in main

   // Enable filter to log the information contained in the lib.
    let filter_layer = EnvFilter::try_from_default_env()
        .or_else(|_| {
            // We can add this through clap
            if opts.verbose {
                EnvFilter::try_new("debug")
            } else {
                EnvFilter::try_new("info")
            }
        })
        .unwrap();

    // Run tracer.
    tracing_subscriber::fmt()
        .without_time()
        .with_env_filter(filter_layer)
        .with_writer(std::io::stderr)
        .init();

and in Cargo.toml

tracing = "^0.1"
tracing-subscriber = { version = "^0.3", features = ["env-filter"] }

[Luni-4]

Can we write mod utils and import things as use crate::crate_name::function?

[Luni-4]

Instead of String we can use Cow in this way we can write:
start_log_group("Something") and start_log_group(format!("something")). I guess we just need to write a generic that implements Into<Cow>

[Luni-4]

We can use pub(crate) or remove the visibility attribute if they are used in the same file

[Luni-4]

@dcvz

This new logging seems a bit complicated, I was proposing to replace println! with info! macro from tracing. Adding this new macros and series of matches complicates the code in my opinion

[dcvz]

@Luni-4 if we want a logger, then I'd say let's do it right. This make sure it outputs correctly also to the Github Action logs, meaning we'll be able to see highlighted warnings and errors easier. It's also just about the same amount of boilerplate for the changes you were asking for logger, tracer and using Cow.

IMO - I think this is fine.. but I guess its up to you all to decide.

[Luni-4]

I'm not against this new logger, just saying that is more complete, perhaps this is the right term, of what I have thought, but I'm fine with it

[dcvz]

@louisfd @nathanielsimard this one is ready to go!

[nathanielsimard]

Why use a different rendering depending of the CI? can ::group::{} works everywhere? Same question for all other occurences.

[dcvz]

well, in Github Actions, ::group:: creates a grouped log that can be minimized / maximized. In our normal shells it doesn't really do anything except actually print out ::group::Title -- I thought this might be neater. But if we don't mind printing out ::group:: in our normal developer shells, then we don't need different rendering.