-
Notifications
You must be signed in to change notification settings - Fork 135
Add build statistics to Log Manifest Entry, exact build duration #208
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
base: master
Are you sure you want to change the base?
Conversation
|
cc: @AvdLee I'm likely to pull this into my fork which repairs the function/typecheck timings, since I think this would be quite useful for us |
|
@aleksandergrzyb asked to re-review this. Small changes, just SwiftLint fixes and Sendable support! |
| let totalNumberOfTestFailures = primaryObservable["totalNumberOfTestFailures"] as? Int, | ||
| let highLevelStatus = primaryObservable["highLevelStatus"] as? String | ||
| else { | ||
| throw LogError.invalidLogManifest("The file at \(path) is not a valid " + |
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.
If we throw if those metrics are absent, and per your comment it's a change in a recent Xcode version, won't this be a breaking change for developers using this library with older Xcode versions? If so, I recommend to making statistics optional, and then add a comment for future reference where we indicate from which version of Xcode the attribute becomes present.
I've updated
LogManifestEntryfor Xcode's latest format, adding statistics like number of warnings and errors. This allows to filter out failed builds without loading.xcactivitylog.I've also changed the build duration from an
Intinto aDoubleand removed the rounding, so build durations are more precise. I believe it's up to the users of the framework to decide to round the build duration instead of us showing wrong build durations from the start.