feat: summarize information from debug logs

[CatalinSnyk]

Description

• Adding some basic matching for notable/useful information from debug logs.

Checklist

• Tests added and all succeed (make test)
• Regenerated mocks, etc. (make generate)
• Linted (make lint)
• Test your changes work for the CLI - PR

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Toolchain Incompatibility 🟠 [major] The function writeSection uses strings.SplitSeq, which was introduced in Go 1.23. If the project's go.mod or the environment's toolchain is at a lower version (e.g., Go 1.21 or 1.22, common in many enterprise CI environments), this will cause a compilation failure. Use strings.Split or bufio.Scanner for better compatibility. for line := range strings.SplitSeq(content, "\n") { High Memory Pressure 🟡 [minor] In Summarize, the code creates a new slice of strings msgs with the same length as the lines slice, effectively doubling the memory required to hold the log content. For very large debug logs (which can exceed 100MB in complex CLI operations), this may lead to unnecessary OOMs. Consider processing the log line-by-line using a scanner or modifying the strings in place if possible. msgs := make([]string, len(lines)) for i, line := range lines {

📚 Repository Context Analyzed This review considered 12 relevant code sections from 11 files (average relevance: 1.00) internal/presenters/components.go (2 segments, lines 1-293) internal/ufm_helpers/remediation.go (lines 1-275) internal/presenters/funcs.go (lines 1-251) pkg/utils/sarif/sarif.go (lines 1-248) pkg/local_workflows/local_models/transform.go (lines 1-250) pkg/local_workflows/ignore_workflow/ignore_workflow.go (lines 1-98) pkg/local_workflows/auth_workflow.go (lines 1-183) ... and 4 more file(s)

[danskmt]

is there any scenario where Line, Kind or Message would be empty / not present?

[CatalinSnyk]

I think not, Line is always i+1 ≥ 1; Kind is always one of the four constants set by classify; and classify("") returns false, so empty/whitespace messages never become highlights.

[danskmt]

this seems very hacky, not sure if there are better ways of doing this

[CatalinSnyk]

Agreed, I'll follow-up on it

[danskmt]

I'm thinking if is possible to work with templates instead of doing these manipulations... Have you considered those / had impediments regarding them?

[CatalinSnyk]

Not quite sure, what kind of templates did you have in mind?

Templates that we have in GAF (for our presenter) are better for rendering: if we used templates for rendering the CLI header/footer then I think it could be a bit more viable, but for matching the current log header/footer section I don't think it would make much sense.

[danskmt]

@CatalinSnyk also, bot left some comments that might be relevant:

[CatalinSnyk]

@CatalinSnyk also, bot left some comments that might be relevant:

• The CLI is on 1.26 (same as the version in go.mod in this project) - I don't think this should be an issue
• This doesn't seem quite right, since we are matching we would return substrings. The scanner/streaming of logs could be something we follow-up on ticket, I'm more keen to keep it simple for now.