-
Notifications
You must be signed in to change notification settings - Fork 370
feat(cli): allow specifying log filters #6513
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
Conversation
6b585a0 to
ab4ecb9
Compare
|
+1 Great idea ! |
Filter CLI logs by span prefix. Multiple filters can be specified and exclusion take precedence. Signed-off-by: Georgi Dimitrov <[email protected]>
Check function return values Signed-off-by: Georgi Dimitrov <[email protected]>
ab4ecb9 to
fe7fd2c
Compare
Signed-off-by: Georgi Dimitrov <[email protected]>
nicks
left a comment
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.
hi! thanks for the contribution!
i like the overall motivation and direction
i think my major concern with this PR is that we already have a log filtering system in the UI. This system is similar but subtly different.
What do you think of modifying it to work more like the UI's filtering system? in other words: filter by log type (all vs runtime vs build), filter by resource
span ids were always kind of an internal implementation detail that's not exposed anywhere else, so filtering by span id seems kinda weird to me.
|
Hi, yes, I figured using the span IDs would be controversial but I chose it as it provides the greatest flexibility. I am happy to refactor this to be more in line with the UI log filtering. Let me see what I can come up with. Are these the features that I should limit it to?
|
|
re: 1) ya, right now, build log includes re: 2) let's use re: 4) I'd probably skip |
Match the UI log filtering implementation as closely as possible. Signed-off-by: Georgi Dimitrov <[email protected]>
28c4ad3 to
7db08b8
Compare
|
Hi @nicks, Could you, please, have a look at the latest changes? |
Signed-off-by: Georgi Dimitrov <[email protected]>
nicks
left a comment
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.
lgtm!
Implements tilt-dev#6652 - adds filtering and JSON output capabilities to tilt logs: - --since: Filter logs by time (e.g., "5m", "1h", "30s") - --tail: Limit output to last N lines (applies only to initial history when combined with -f/--follow) - --json: Output logs as JSON Lines (JSONL) format - --json-fields: Configure JSON output fields ("minimal", "full", or comma-separated field list) Implementation details: - Extends LogFilter with Since/Tail fields and time-based filtering - Adds JSONPrinter for structured JSONL output with configurable fields - Uses pointer types in JSONLogLine to distinguish "not included" from "empty value" for --json-fields=full - LogStreamer tracks isFirstBatch to apply tail only to initial history Follows existing patterns from --level and --source flags (PR tilt-dev#6513).
Implements tilt-dev#6652 - adds filtering and JSON output capabilities to tilt logs: - --since: Filter logs by time (e.g., "5m", "1h", "30s") - --tail: Limit output to last N lines (applies only to initial history when combined with -f/--follow) - --json: Output logs as JSON Lines (JSONL) format - --json-fields: Configure JSON output fields ("minimal", "full", or comma-separated field list) Implementation details: - Extends LogFilter with Since/Tail fields and time-based filtering - Adds JSONPrinter for structured JSONL output with configurable fields - Uses pointer types in JSONLogLine to distinguish "not included" from "empty value" for --json-fields=full - LogStreamer tracks isFirstBatch to apply tail only to initial history Follows existing patterns from --level and --source flags (PR tilt-dev#6513). Signed-off-by: Big Boss <[email protected]>
Filter CLI logs by span prefix. Multiple filters can be specified and
exclusion takes precedence.
For example:
tilt up --log-filters 'pod'tilt up --log-filters '!pod'tilt up --log-filters 'pod' --log-filters 'build'ortilt up --log-filters 'pod,build'tilt up --log-filters '!pod' --log-filters '!build'ortilt up --log-filters '!pod,!build'tilt up --log-filters '!pod' --log-filters 'pod:my-namespace:my-pod'ortilt up --log-filters '!pod,pod:my-namespace:my-pod'Also fix a golangci-lint (errcheck) error which was not introduced by this change.