invertase / melos

🌋 A tool for managing Dart projects with multiple packages. With IntelliJ and Vscode IDE support. Supports automated versioning, changelogs & publishing via Conventional Commits.
https://melos.invertase.dev/~melos-latest
Apache License 2.0
1.16k stars 205 forks source link

request: suppress all output but errors #556

Open solshark opened 1 year ago

solshark commented 1 year ago

Is there an existing feature request for this?

Command

No response

Description

I'm running big project with 15+ packages (libs + apps) on CI server with gitlab-runner. Melos output is huge even for success path, so it would be awesome to silent all output except errors.

Reasoning

It will be useful 'coz it will simplify CI logs analysis. Could you imagine CI pipeline running 'get' per package just pruning package name. My output is XX thousands lines, 4-5 of them is simply notes like that:

[email_delivery_service]: + webview_flutter_platform_interface 2.4.0
[email_delivery_service]: + webview_flutter_wkwebview 3.7.3
[email_delivery_service]: + webview_windows 0.1.9 (0.3.0 available)
[email_delivery_service]: + win32 5.0.6
[email_delivery_service]: + win32_registry 1.1.1
[email_delivery_service]: + window_manager 0.3.5

Please consider flag to suppress all output.

Additional context and comments

No response

luanpotter commented 3 months ago

I was about to make the very same suggestion!

Rationale

This is part of Flame's output when running melos analyze:

Warning: large screenshot

I can't even screenshot the whole thing, due to how big it is. As @solshark mentioned, it can get a bit unhinged. Same for melos format, melos run test, etc.

This is an example run of tests on CI, it is quite hard to find the actual broken test.

Proposal

My proposal would be to add a --quiet flag to commands like analyze, format, run, exec.

When this flag is present, "blocks" that had no errors or warnings whatsoever are completely omitted.

Luckily, melos already employs the concept of "blocks" in order to support concurrent execution.

In fact the code is already structured with three layers of abstraction:

image

In this case, we can easily hook up into the MelosLogger layer, as it already understands the necessary concepts of batching and grouping. We only would need to hold the concept of a "status" or "log level" for each group, and consider the --quiet flag in order to update the function flushGroupBufferIfNeed.

I believe the necessary changes would be quite simple all things considered (at least as a first step for analyze & format - run/tests could prove more difficult); and if this here Rationale & Proposal make sense, I would love to contribute with a PR to implement this. It would make parsing results both locally and on CI for our flame monorepo much easier!

spydon commented 3 months ago

@luanpotter sounds good, I'm thinking that it would be good if the quiet option could be global and not specific to commands in the end, and that it can also be specified directly in melos.yaml.

For the tests, that's why we used spec for that previously (which integrates with Melos), but we never figured out why that sometimes stopped working in the CI (most likely running out of memory).

luanpotter commented 3 months ago

I like that idea @spydon! I think it makes sense for it to be both an ad-hoc option and also allowed to be specified globally.