use quiet about checkout

[timotheecour]

group doesn't help much if you're reading raw logs... can we please have --quiet option?

[Allon-Guralnek]

The amount of logs this generates is insane. Please consider at least giving us the option to quiet it down.

[froger-me]

Please reopen

[kokosing]

For big project like https://github.com/trinodb/trino where we have plenty of jobs (currently 35) we we run very often (like 40 times per day). We are pretty sure that is working just fine as it has never failed for us (at least I don't recall a case), but still every single log file has about 170 lines with git progress that does not add any value. We usually read the raw log file as UI is not responsive with such huge log files (browser is not much responsive too but it is a bit better with raw files).

Maybe we could have debug option to troubleshoot problems with there are issues with checkout instead? And have --quite to be used by default?

[FernandoMiguel]

This is what I get for half reading comments while having breakfast.
Cheers

[wipe2238]

When you watch the workflow running, you won't feel the git fetch is hanging.

Problem is, Actions tab really have problems with handling long and quickly updating steps, up to the point that it's freezing browser while action is running. That's UI issue, not anything wrong with action itself, but actions/checkout is usually running early, and is used in most workflows around.
So i can't watch workflow running anyway, unless i open tab only after checkout finishes and live log is hidden :/

TL;DR i'd like having quiet here, just to have live preview actually working; frontend team failed to deliver, so maybe backend team can make it happen ;)

[simonbaird]

FYI I think I have a good solution for this, see #1067 .

[TingluoHuang]

We can provide an option to turn on --quite
There are 2 reasons we have --progress

• When you watch the workflow running, you won't feel the git fetch is hanging.
• When you try to investigate why my checkout action is slow, the progress output can give some idea about how many objects you are fetching and what's the average object download speed.

[FernandoMiguel]

Didn't know the command option was available.
Maybe add it to the docs?
Thanks

[TingluoHuang]

@FernandoMiguel we don't have it right now, we can consider adding it. 😄

[FernandoMiguel]

The docs or the flag? 🤔

[TingluoHuang]

the flag. 😄

[FernandoMiguel]

Damn it...
That explains why my build failed lol
Git revert Ahah

[moltar]

Agree with OP, the log seems to be quite verbose:

Receiving objects:   6% (19/304)

                                                                                
Receiving objects:   7% (22/304)

                                                                                
Receiving objects:   8% (25/304)

                                                                                
Receiving objects:   9% (28/304)

                                                                                
Receiving objects:  10% (31/304)

                                                                                
Receiving objects:  11% (34/304)

                                                                                
Receiving objects:  12% (37/304)

                                                                                
Receiving objects:  13% (40/304)

                                                                                
Receiving objects:  14% (43/304)

                                                                                
Receiving objects:  15% (46/304)

But I can also see it being useful.

I wish there was a way to disable that though. I am not really watching checkout ever.

[ericsciple]

Marking as enhancement and I'll defer to others.

Personally, +1 what @TingluoHuang said. Sense of motion and timestamps are good for us to help customers. I'm generally hesitant to add extra inputs (overload user with options).

[sauyon]

I feel like the real solution here would be to add support for the carriage return clearing the line.

[ericsciple]

Output from the step is now grouped so that should help.

[grosser]

@ericsciple plz reopen, it's still wasteful/unhelpful to have all these extra log lines
quiet as default and a flag to undo would be great

[rgoliveira]

Just to add another POV: depending on how many jobs/runs and the nature of them, a repo can quickly use large amounts of storage space to accommodate these logs. I fail to see how the proposed flag could be a problem.