Various improvements around logging & JSON #9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using the JSON logging backend, tracing expects the fields to have been formatted as a JSON string. However, the layer wasn't set up properly for that, resulting in a variety of "field_error"s in the logs (and panics on debug builds). As it turns out, we were setting it up in an overcomplicated way regardless, so use the simpler helper functions in tracing that set all of this up for us. Signed-off-by: Ryan Gonzalez <[email protected]>
While thinking on #6 and the accidental / intentional use of gitlab.output, it occurred to me that the way we show errors for GitLab is not actually how we'd want them logged with JSON logging (which currently dumps the entire error string, *including ANSI codes*, inside the JSON objects). With this in mind, I realized we can get the color-eyre handler's span traces and just convert it to JSON manually. This would be all, if we could actually log JSON from tracing. Unfortunately, any extra fields logged are converted to strings via Debug and stored as such in the JSON fields. That means we end up with our beautiful JSON errors stuck as strings and filled with dozens of escape sequences, which also makes them entirely unreadable without taking the JSON apart. But! tracing has "unstable" (can change in a bugfix release, but isn't that what Cargo.lock is for anyway?) functionality that integrates with the valuable crate, such that any field value that's a Valuable will be serialized as JSON. So, the eyre Report is converted to an intermediate Valuable that gets sent to tracing, which dutifully serializes it as an actual JSON object. This does, however, still have an unfortunate missing piece, which is serializing the fields in the span trace. tracing-error serializes fields into a string to be retrieved when the span trace is collected, which isn't the JSON format we would want. Now, this *can* be changed to format JSON, but that's not very useful because: - It means that span trace fields will be shown as JSON in the GitLab logs too, which isn't great. - There is no straightforward way to go from a JSON string to a Valuable: valuable only includes ways to go serialize a Valuable via Serde, without any way of *deserializing*. This would only be possible by manually converting everything, which is increasing the already-high complexity. In practice, the individual field values don't really have complex JSON values, so leaving the default non-JSON formatting there is fine. Signed-off-by: Ryan Gonzalez <[email protected]>
Terminology like "build status" and "dirty" isn't super helpful, so try to make it clearer what's going on. Signed-off-by: Ryan Gonzalez <[email protected]>
This can happen due to e.g. configuration issues on the repo, so it makes sense to log it somewhere other than just the service logs. Signed-off-by: Ryan Gonzalez <[email protected]>
|
The one thing i don't like here is the amount of boilerplate/scaffolding that's being added for logging; That's really something we should see if we can improve in the runner crate itself rather then having all these gymnastics in a runner implementation |
em-
reviewed
Feb 8, 2024
There was a problem hiding this comment.
Looks good to me, but for an actual review you need @sjoerdsimons.
| previous_code = Some(code); | ||
| } | ||
|
|
||
| tokio::time::sleep(options.sleep_on_building).await; | ||
| } | ||
| PackageBuildState::Dirty => { | ||
| if !was_dirty { | ||
| outputln!("Package is dirty, trying again later..."); | ||
| outputln!( | ||
| "Package build is dirty / being re-scheduled, \ |
There was a problem hiding this comment.
Maybe "Package build status is being re-calculated"?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commits have more detailed descriptions of the changes, the TLDR is that I wanted errors to be formatted normally in the service logs and ended up down a terrifying rabbit hole. Supersedes #6.