[GH-ISSUE #1567] Reduce logs in act CI #788

Closed
opened 2026-03-01 21:46:23 +03:00 by kerem · 3 comments
Owner

Originally created by @lavigne958 on GitHub (Jan 18, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/1567

Act version

master

Feature description

Overview

Reduce the log footprint in the CI (currently using github action).
The logs from the CI workflow test-linux reaches over 70K log lines.
It could help putting some of them in a log file

Details

The current CI prints a lot of informations: the go test logs (test name, test result,...) and the logs from act itself.

We reach over 70K log lines in each run, just for the step go test. We could reduce that by putting the logs from act into a dedicated file.

Limitations

The issue/limitation with this is that if we need the logs from act in order to understand a failing test we need to be able to retrieve that log file for that test (yes, having a log file for each test is better 😉 ).

That means we must some how upload that files to some packages storage and have it cleaned after some time (15 days is enough ?? ) that require extra work on the CI (cron jobs running that list packages and clean log files that are too old).

We can find other solutions for that, as long as we split the logs from the go test command from the act logs we'll make the CI output much easier to read.

Originally created by @lavigne958 on GitHub (Jan 18, 2023). Original GitHub issue: https://github.com/nektos/act/issues/1567 ### Act version master ### Feature description ## Overview Reduce the log footprint in the CI (currently using github action). The logs from the CI workflow `test-linux` reaches over 70K log lines. It could help putting some of them in a log file ## Details The current CI prints a lot of informations: the go test logs (test name, test result,...) and the logs from `act` itself. We reach over 70K log lines in each run, just for the step `go test`. We could reduce that by putting the logs from `act` into a dedicated file. ## Limitations The issue/limitation with this is that if we need the logs from `act` in order to understand a failing test we need to be able to retrieve that log file for that test (yes, having a log file for each test is better :wink: ). That means we must some how upload that files to some packages storage and have it cleaned after some time (15 days is enough ?? ) that require extra work on the CI (cron jobs running that list packages and clean log files that are too old). We can find other solutions for that, as long as we split the logs from the `go test` command from the `act` logs we'll make the CI output much easier to read.
kerem 2026-03-01 21:46:23 +03:00
Author
Owner

@catthehacker commented on GitHub (Jan 19, 2023):

Is there any reasonable goal in that we add complexity to CI just to have logs be in different file?

<!-- gh-comment-id:1397410668 --> @catthehacker commented on GitHub (Jan 19, 2023): Is there any reasonable goal in that we add complexity to CI just to have logs be in different file?
Author
Owner

@lavigne958 commented on GitHub (Jan 19, 2023):

Yes, when trying to contribute to the project, if a step fails it makes it much easier to read only golang output to identify the faulty test and then read the test output elsewhere. Or specifically run that test locally, or something else depending on the solution of choice.

In a word: it makes it easier for people to contribute.

<!-- gh-comment-id:1397485445 --> @lavigne958 commented on GitHub (Jan 19, 2023): Yes, when trying to contribute to the project, if a step fails it makes it much easier to read only golang output to identify the faulty test and then read the test output elsewhere. Or specifically run that test locally, or something else depending on the solution of choice. In a word: it makes it easier for people to contribute.
Author
Owner

@ChristopherHX commented on GitHub (Jan 23, 2023):

Ok now I understand what you mean, I haven't seen this warning in the webconsole before:

This step has been truncated due to its large size. Download the full logs from the menu once the workflow run has completed.

Instead of changing the log, I would prefer to create a github step summary (markdown). Containing the test summary (and logs of failed tests).

Actions also have artifacts for random files like log, with a built in retention period.
Both could be generated by a javascript wrapper of go test.

<!-- gh-comment-id:1400208823 --> @ChristopherHX commented on GitHub (Jan 23, 2023): Ok now I understand what you mean, I haven't seen this warning in the webconsole before: > This step has been truncated due to its large size. Download the full logs from the menu once the workflow run has completed. Instead of changing the log, I would prefer to create a github step summary (markdown). Containing the test summary (and logs of failed tests). Actions also have artifacts for random files like log, with a built in retention period. Both could be generated by a javascript wrapper of go test.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/act#788
No description provided.