-
Notifications
You must be signed in to change notification settings - Fork 315
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
Yarn info parsing fixes #9328
Yarn info parsing fixes #9328
Conversation
1756004
to
4b81b04
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #9328 +/- ##
=========================================
Coverage 67.45% 67.45%
Complexity 1200 1200
=========================================
Files 241 241
Lines 8498 8498
Branches 904 904
=========================================
Hits 5732 5732
Misses 2402 2402
Partials 364 364
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
a12ad89
to
e297b5a
Compare
internal fun parseYarnInfo(stdout: String, stderr: String): PackageJson? = | ||
extractDataNodes(stdout, "inspect").firstOrNull()?.let(::parsePackageJson).alsoIfNull { | ||
extractDataNodes(stderr, "error").forEach { | ||
logger.warn { "Error parsing yarn info: ${it.jsonPrimitive.content}." } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nits:
- "yarn" -> "Yarn"
- Probably drop the trailing "." as
content
could already contain it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, as these are errors on the Yarn side, should be log to error level, too? This would even make more sense when also parsing for warnings explicitly in a follow-up commit, as these would then be logged as warnings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As ORT's execution still is "successful" (you can rely on the result), I would propose to log the
errors as "warnings". (And then in a following change log warnings either as info or debug).
Would you agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, makes sense to me.
e297b5a
to
58af405
Compare
58af405
to
5f0b70d
Compare
This is a fix-up for ad9a363. Signed-off-by: Frank Viernau <[email protected]>
Signed-off-by: Frank Viernau <[email protected]>
Prepare for an upcoming change that signals that parsing of `PackageJson` data was unsuccessful. Signed-off-by: Frank Viernau <[email protected]>
This function is not suitable for parsing the JSON objects on `stderr` as-is. Signed-off-by: Frank Viernau <[email protected]>
Avoid code duplication in an upcoming change. Signed-off-by: Frank Viernau <[email protected]>
Previously, calling `parseYarnInfo(process.stderr)` was useless, because it attempts to only parse a `PackageJson` instance from `stderr` which always fails, because `yarn` does not output such data to `stderr`. However, in [1] the logging of errors obtained from `stderr` got (partially) removed. Fix this up by logging any errors found in `stderr` in case no `PackageJson` instance could be parsed from `stdout`. [1]: ad9a363 Signed-off-by: Frank Viernau <[email protected]>
5f0b70d
to
f6f9054
Compare
See individual commits.
Part of #9261.