Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rush] Ideas for Summarizer improvements #4998

Open
witcher112 opened this issue Nov 8, 2024 · 3 comments
Open

[rush] Ideas for Summarizer improvements #4998

witcher112 opened this issue Nov 8, 2024 · 3 comments

Comments

@witcher112
Copy link
Contributor

witcher112 commented Nov 8, 2024

Intro

Hi everyone!

I want to follow-up on the discussion from today's Rush Hour about potential Summarizer improvements.

Right off the bat, I can say I'm willing to help working on them, but beforehand I think it would be best to have a discussion on how to approach them.

I think we can start by sketching out different use cases and come up with various solutions.

Issue

Summarizer doesn't provide complete outputs of commands/phases making it hard to learn why particular project fails to build/test etc.

When working with editors like VSCode

Proposal #VSCode-1 - display path to *.log files

Since VSCode is able to detect file paths in the terminal as well as in the editor, it's possible to simply print the path to the generated log file so the developer would be able to access them just with Ctrl + Mouse Click.

Advantages:

  • easy to develop
  • could be opt-in (through argument like --print-log-paths)

Disadvantages: (I can't think of any)

Proposal #VSCode-2 - create a VSCode problem matcher

(not mine, proposed by someone else during Rush Hour, I'm just trying to start exploring this option)

We can introduce a custom VSCode problem matcher that would display errors in the "Problems" tab.

From my understanding of how these work, it could either:

  • detect problems from the terminal
  • detect problems from logs files

Advantages:

  • uses built-in UI of VSCode made for reviewing problems

Disadvantages:

  • (in case of detecting problems from the terminal) all errors would need to be printed anyway
  • hard to develop (I guess it would need to support each tool individually as TypeScript, ESLint, etc. display errors in different formats)
  • VSCode exclusive

When reviewing logs from CI

Proposal #CI-1 - display X last lines

Advantages:

  • moderately easy to develop
  • could be opt-in and configurable (through arguments like --print-log-last-lines and --print-log-last-lines-count

Disadvantages:

  • hard to predict good amount of last lines to print as it varies between tools (while 10 should be enough for TypeScript Compiler, it could cut out results of some test runners)

Proposal #CI-2 - use AI summarizing

Just throwing out the idea, not sure if it's even possible/acceptable for tools like rush to leverage AI summarizing.

Advantages:

  • if there are tons of errors, it could give a general idea of what's wrong
  • could be opt-in (through argument like --print-log-ai-summarize)

Disadvantages:

  • not consistent
  • most probably hard to develop and introduces a new stack of dependencies
  • could be slow and require an internet connection (depending on implementation)

My thoughts

As I don't heavily use CI, I want to limit my thoughts to the VSCode case only as I'm primarily interested in it.

The #VSCode-1 proposal could be the best way to start working on improvements here as it doesn't pollute the output too much but provides a quick and easy way to inspect all errors. Also, the fact that it could be opt-in makes it somewhat non-intrusive.

Please let me know what you think about it, I'm heavily motivated to push this topic forward :D

@witcher112
Copy link
Contributor Author

Here's draft PR for #VSCode-1 proposal: #4999

@dmichon-msft
Copy link
Contributor

I'm the primary advocate for integration with problem matchers; the request is not to implement a problem matcher into VSCode, but to integrate VSCode's problem matcher system into Rush, so that Rush can consume custom-defined problem matchers and use them to extract errors/warnings from the underlying tools' build logs.

@witcher112
Copy link
Contributor Author

I'm the primary advocate for integration with problem matchers; the request is not to implement a problem matcher into VSCode, but to integrate VSCode's problem matcher system into Rush, so that Rush can consume custom-defined problem matchers and use them to extract errors/warnings from the underlying tools' build logs.

So once extracted, they should be provided to VSCode so they're displayed in "Problems" tab, do I get it right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: General Discussions
Development

No branches or pull requests

2 participants