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

Log lines from builders are really long #1069

Closed
jakemac53 opened this issue Feb 28, 2018 · 4 comments · Fixed by #1100
Closed

Log lines from builders are really long #1069

jakemac53 opened this issue Feb 28, 2018 · 4 comments · Fixed by #1100

Comments

@jakemac53
Copy link
Contributor

Just the description of the logger can be really long today, for instance [SEVERE] Instance of 'DevCompilerBuilder' on e2e_example|web/sub/main.module: .

This is partly because of the default toString for objects and partly because we include the full primary input id in the description.

We could leave it as is and always add newlines after the description, or we could try to shorten the descriptions in some way, but I think we should do something to clean it up.

@natebosch
Copy link
Member

I'm in favor of having better toStrings on these builders. I would prefer not to reduce the amount of information we have in these.

@jakemac53
Copy link
Contributor Author

Should we consider trying to add some default cleaning up of the toString, just something really simple to handle this case?

if (builderString.startsWith("Instance of '")) {
  builderString = builderString.substring("Instance of '".length, builderString.length - 1);
}

@natebosch
Copy link
Member

synced offline, I think what we want to do is to track the builder key all the way through to the BuildAction and use that for the log message instead of the builder's toString.

Some other tweaks we want:

  • Avoid <package>|<package> for 'simple' builder keys
  • Remove package name from asset IDs when they are the root package
  • Change asset ID into package: format instead of using the | format.

@matanlurey
Copy link
Contributor

  • Change asset ID into package: format instead of using the | format.

YES THIS PLEASE GOD THIS.

natebosch added a commit that referenced this issue Mar 6, 2018
Closes #1069

Replaces the builder `toString()` with a more relevant label, and
changes AssetIds to something more reconizable.

- Keep a `buildLabel` on `BuildAction`. Where possible this is a
  `builderKey`, but when that is missing or empty we fall back on the
  `toString` of the Builder.
- Normalize AssetIds to `package:` URIs for non-root packages, and file
  path for root package.
- Don't prefix newlines as messages are logged, these weren't working as
  implemented and would get swallowed by the StdIoLogger anyway.
- Hardcode known `build_runner` Logger names and don't print their name
  with messages.
- Always prefix messages from Builders (loggers with names we don't
  recognize) with a newline. This works well in the WARNING and SEVERE
  case but might not work as well for other messages - we can revist if
  necessary.
- Don't print stack traces unless verbose logging is enabled.
natebosch added a commit that referenced this issue Mar 7, 2018
Closes #1069

Replaces the builder `toString()` with a more relevant label, and
changes AssetIds to something more reconizable.

- Keep a `buildLabel` on `BuildAction`. Where possible this is a
  `builderKey`, but when that is missing or empty we fall back on the
  `toString` of the Builder.
- Normalize AssetIds to `package:` URIs for non-root packages, and file
  path for root package.
- Don't prefix newlines as messages are logged, these weren't working as
  implemented and would get swallowed by the StdIOLogger anyway.
- Hardcode known `build_runner` Logger names and don't print their name
  with messages.
- Prefix messages from Builders (loggers with names we don't
  recognize) with a newline for WARNING level and higher.
- Don't print stack traces unless verbose logging is enabled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants